# Kindo Documentation — Full Content

> Complete documentation content for LLM ingestion. Each section below is one documentation page.

---

## Connecting Integrations

Source: https://docs.kindo.ai/connecting-integrations/

These guides walk through the provider-side configuration required to connect specific integrations to Kindo.

---

## Customer Training Session

Source: https://docs.kindo.ai/learning/customer-training-session/

## Session Metadata

| Field | Value |
| --- | --- |
| Format | Virtual (~2.5 hours) |
| Audience | Cybersecurity engineers |
| Session Type | Pilot cohort (scaling to additional batches) |

## Session Objective

Each participant builds a Kindo workflow agent independently by session end, including at least one workflow that uses live integrations through agentic tool calling.

:::tip
Design principle: get participants into the product within the first 10 minutes. Lead with hands-on experience, then explain what they just experienced.
:::

## Training Agenda

### Block 1 - Platform Orientation (45 min)

| Time | Topic | Content |
| --- | --- | --- |
| 0:00-0:10 | Welcome and Context | Facilitator introduction. Why Kindo, what the customer is building toward, and session objectives. |
| 0:10-0:20 | AI Chat First Steps | Live demo: everyone opens Kindo, asks a question in AI Chat. Show model selection and file upload. |
| 0:20-0:35 | Platform Overview and Agent Types | What Kindo is, deployment models, chatbots vs workflow vs triggered agents, LLM steps, action steps, API action steps. |
| 0:35-0:45 | Integrations Overview | How integrations work. Relevant stack: CrowdStrike, Jira, ServiceNow, Splunk. |

Key takeaway: participants have used the product, understand the three major agent types, and know how integrations fit into workflows.

### Transition (5 min)

| Time | Activity | Details |
| --- | --- | --- |
| 0:45-0:50 | Setup and Questions | Open Kindo, confirm access, address any platform questions before exercises begin. |

### Block 2 - Hands-On Workshop (65 min)

| Time | Activity | Focus |
| --- | --- | --- |
| 0:50-1:15 | Exercise A - Firewall Rule Optimizer (25 min) | Prompt engineering, Knowledge Stores, and multi-step workflows |
| 1:15-1:20 | Break (5 min) |  |
| 1:20-1:55 | Exercise B - Universal Security Triage Agent (35 min) | Integrations and agentic tool calling |

Key takeaway: participants build two agents end to end — from structured prompting and knowledge stores to integration-powered autonomous triage.

### Block 3 - Apply and Extend (25 min)

| Time | Activity | Details |
| --- | --- | --- |
| 1:55-2:00 | Briefing | Pick your own use case, extend a workshop agent, or fork a prebuilt template. |
| 2:00-2:15 | Independent build time | Participants build agents for their own workflows. |
| 2:15-2:20 | Show and tell (optional) | 2-3 volunteers share what they built. |

### Block 4 - Wrap-Up and Next Steps (15 min)

| Time | Activity | Details |
| --- | --- | --- |
| 2:20-2:25 | Key concepts recap | Agent types, steps, knowledge stores, prompt engineering, integrations |
| 2:25-2:30 | Ongoing resources | Documentation site, learning center, reference materials |
| 2:30-2:33 | Scaling plan and action item | Build one agent for your actual work by Friday |
| 2:33-2:35 | Q&A and feedback | Open questions and feedback form |

:::note
Block 2 is the highest-value section. If timing slips earlier in the session, preserve full exercise time.
:::

## Pre-Session Checklist

## Exercises

## Reference Materials

---

## Pre-Session Checklist

Source: https://docs.kindo.ai/learning/customer-training-session/pre-session-checklist/

Share this checklist 3-5 days before the session.

## 1. Confirm Account Access

:::note
If you're already signed into a separate Kindo account, sign out or use an incognito window for the links below.
:::

- Look for an email from Kindo with subject: **"You've been invited by bryan+deloittetraining@kindo.ai to join Kindo"**
- Click on the link to join the org.
- Choose **"Continue with email"** to sign in. Enter your email like this: `{your email}+training@deloitte.com`
  - For example, if your email is `joe@deloitte.com`, enter `joe+training@deloitte.com` in the email box.
- Look for an email from **Kindo** with subject **"Your Kindo sign-in code"** in your email. Enter the code on the sign-in page.
- After this it should take you to [app.kindo.ai](https://app.kindo.ai).
- If you cannot sign in, contact your training coordinator immediately.

## 2. Browser and Setup

- Use the latest Chrome or Edge.
- Confirm a stable internet connection.
- Use a display setup that supports split-view (training guide on one side, Kindo on the other).

## 3. Prepare a Use Case (Optional)

- Think of one workflow from your daily work that you want to automate.
- You will have independent build time in Block 3, so this helps you move faster.

## 4. What To Expect

- A virtual ~2.5-hour session: orientation, hands-on exercises, and independent build time.
- Two workflow agents built during the session.
- No prior AI or ML background required.

:::tip
Prepare one specific workflow question in advance. Participants who bring concrete examples usually get better outcomes during Block 3.
:::

## Session Links

- Session overview: [Customer Training Session](/learning/customer-training-session/)
- Exercise A: [Firewall Rule Optimizer](/learning/customer-training-session/exercises/firewall-rule-optimizer/)
- Exercise B: [Universal Security Triage Agent](/learning/customer-training-session/exercises/universal-triage-agent/)

---

## Learning Center

Source: https://docs.kindo.ai/learning/

The Learning Center is where Kindo training programs live. Each session includes a clear agenda, participant setup checklist, hands-on exercises, and reusable reference guides.

:::note
This section is participant-facing. Facilitator-only operational notes and provisioning details are intentionally excluded.
:::

## Available Sessions

## What You Will Find In Each Session

- Session overview with goals, audience, and full agenda timing
- Pre-session checklist for access and setup
- Hands-on exercises with prompts and troubleshooting
- Reference materials you can reuse after training

## Coming Next

More sessions and reusable guides are planned, including additional security workflows, cross-functional playbooks, and deeper integration design patterns.

---

## Agents API quickstart

Source: https://docs.kindo.ai/apis/agents/quickstart/

The Agents API is Kindo's control-plane surface for **discovering**
agents your organization has configured, **triggering** a run, and
**polling** the run for its result. It is HTTP+JSON only — there is
no SDK shim; any HTTP client works.

The flow is:

1. `GET /v1/agents/list` — find the `agentId` you want to run.
2. `GET /v1/agents/{agentId}` — inspect the expected `inputs` labels.
3. `POST /v1/agents/runs` — trigger a run, receive a `runId`.
4. `GET /v1/runs/{runId}` — poll until `status` is terminal.

## Prerequisites

- A Kindo API key (see [Authentication](/overview/authentication/)).
- At least one agent configured for your organization in the Kindo
  Terminal.

## 1. Discover an `agentId`

```bash
curl https://api.kindo.ai/v1/agents/list \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

This endpoint accepts no query parameters and returns the visible
agents in a single page, capped at 500 entries. See
[Request shape → `GET /v1/agents/list`](/apis/agents/request-shape/#get-v1agentslist)
for the cap and envelope details.

```json
{
  "items": [
    {
      "agentId": "18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d",
      "name": "Daily Security Scan",
      "description": "Runs the daily vulnerability check workflow.",
      "createdAt": "2026-03-10T18:45:23.000Z",
      "creatorName": "Security Team",
      "metadata": { "userPermissions": ["view", "edit"] }
    }
  ],
  "total": 1
}
```

## 2. Fetch the input schema

`GET /v1/agents/{agentId}` returns the agent's configuration,
including the `inputs` array — the exact labels you must use when
triggering a run.

```bash
curl https://api.kindo.ai/v1/agents/18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

```json
{
  "agentId": "18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d",
  "name": "Daily Security Scan",
  "description": "Runs the daily vulnerability check workflow.",
  "inputs": ["query"],
  "hasTriggers": false,
  "modelsInUse": ["claude-sonnet-4-5-20250929"],
  "recentRunIds": ["7a7ced7d-95a8-416f-95bb-5c0ff3599f53"],
  "lastRunAtUtc": "2026-03-12T15:00:00.000Z",
  "metadata": { "userPermissions": ["view", "edit"] }
}
```

Each `name` in the run request's `inputs` array must match one of
the strings in this `inputs` list exactly.

### Paginating and filtering `recentRunIds`

The agent endpoint accepts optional `limit`, `cursor`, `startDate`,
and `endDate` query parameters to page through and date-filter the
`recentRunIds` list. When any of these is supplied, the paginated path
uses a default `limit` of 20 and the response adds a `nextCursor` field:
a string when more pages remain, `null` on the last page. Calls without
query parameters keep the legacy response shape and legacy run cap.

```bash
curl "https://api.kindo.ai/v1/agents/18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d?limit=2&startDate=2026-03-12T00:00:00Z" \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

Note: for brevity, this example omits the unchanged agent-config fields
(`name`, `description`, `inputs`, `hasTriggers`, `modelsInUse`, and `metadata`)
shown above. The response shape is the same as the non-paginated example, plus
`nextCursor`.

```json
{
  "agentId": "18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d",
  "recentRunIds": [
    "7a7ced7d-95a8-416f-95bb-5c0ff3599f53",
    "3c1f4e2a-19b8-4d5e-8a2f-b6d1e0c4f7a9"
  ],
  "lastRunAtUtc": "2026-03-12T15:00:00.000Z",
  "nextCursor": "<opaque-cursor-token>"
}
```

Pass the returned `nextCursor` back as `?cursor=…` to fetch the next
page. When you paginate a date-filtered list, re-pass the same
`startDate`/`endDate` on every follow-up request — the cursor does
not encode the date filters, and dropping them silently changes the
page slice. `lastRunAtUtc` is independent of the filters — it always
reflects the agent's true most recent run. See
[Request shape → `GET /v1/agents/{agentId}`](/apis/agents/request-shape/#get-v1agentsagentid)
for the full parameter and response contract.

## 3. Trigger a run

```bash
curl -X POST https://api.kindo.ai/v1/agents/runs \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "agentId": "18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d",
    "inputs": [
      { "name": "query", "value": "Run the daily security scan" }
    ]
  }'
```

The endpoint responds `202 Accepted` with the `runId` and the
`conversationId` backing the run:

```json
{
  "runId": "7a7ced7d-95a8-416f-95bb-5c0ff3599f53",
  "conversationId": "clx9a2b1c0000d4e5f6g7h8i9"
}
```

Poll the run with `runId`. Keep the `conversationId` if you want to
read the run's full message history via the
[Conversations API](/apis/conversations/quickstart/) — the basis for
multi-turn continuity across runs.

## 4. Poll the run

```bash
curl https://api.kindo.ai/v1/runs/7a7ced7d-95a8-416f-95bb-5c0ff3599f53 \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

```json
{
  "runId": "7a7ced7d-95a8-416f-95bb-5c0ff3599f53",
  "agentId": "18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d",
  "conversationId": "clx9a2b1c0000d4e5f6g7h8i9",
  "createdAtUtc": "2026-03-12T15:00:00.000Z",
  "endedAtUtc": "2026-03-12T15:00:08.000Z",
  "result": "{\"role\":\"assistant\",\"parts\":[{\"type\":\"text\",\"text\":\"Security scan complete. No critical findings.\"}]}",
  "status": "success"
}
```

`result` is a JSON-encoded string of the final assistant message
payload — parse with `JSON.parse` to recover the structured
`{ role, parts, ... }` object. It is `null` while `in_progress`,
always `null` on `failure` or `cancelled`, and also `null` on
`success` when the run produced no assistant payload.

`status` is one of `in_progress`, `success`, `failure`, or
`cancelled`. Anything other than `in_progress` is terminal (a
`failure` run can be re-run from the Kindo app, returning it to
`in_progress` — see [Runs](/apis/agents/runs/)); keep polling while `status` is
`in_progress`. See [Runs](/apis/agents/runs/) for the full lifecycle.

## 5. Fetch evaluation results (optional)

If the agent has step-level objectives configured, you can retrieve
per-step verdicts once the run completes:

```bash
curl https://api.kindo.ai/v1/runs/7a7ced7d-95a8-416f-95bb-5c0ff3599f53/evals \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

```json
{
  "runId": "7a7ced7d-95a8-416f-95bb-5c0ff3599f53",
  "result": "pass",
  "steps": [
    {
      "stepNumber": 1,
      "name": "Run the daily security scan",
      "result": "pass",
      "explanation": "Kindo completed the scan and found no critical vulnerabilities."
    }
  ]
}
```

`result` is one of `pass`, `fail`, `pending`, `skipped`, or `unknown`.
See [Runs → `GET /v1/runs/{runId}/evals`](/apis/agents/runs/#get-v1runsrunidevals)
for the full field reference.

## Next steps

- [Request shape](/apis/agents/request-shape/) — every field on every endpoint.
- [Runs](/apis/agents/runs/) — run lifecycle, polling cadence, step-level evals,
  and how runs relate to conversations.
- [Errors](/apis/agents/errors/) — common error envelopes.

---

## Chat Completions API quickstart

Source: https://docs.kindo.ai/apis/chat-completions/quickstart/

`POST https://api.kindo.ai/v1/chat/completions` speaks the OpenAI
[Chat Completions API](https://platform.openai.com/docs/api-reference/chat).
Stock OpenAI clients work unmodified.

## Prerequisites

- A Kindo API key (see [Authentication](/overview/authentication/)).
- A model ID from [`GET /v1/models`](/overview/model-catalog/) —
  for example, `claude-sonnet-4-5-20250929`.

## openai-python

```python

from openai import OpenAI

client = OpenAI(
    base_url="https://api.kindo.ai/v1",
    api_key=os.environ["KINDO_API_KEY"],
)

response = client.chat.completions.create(
    model="claude-sonnet-4-5-20250929",
    messages=[
        {"role": "user", "content": "Explain Kubernetes pod security policies."}
    ],
)

print(response.choices[0].message.content)
```

## openai-node

```ts

const client = new OpenAI({
  baseURL: 'https://api.kindo.ai/v1',
  apiKey: process.env.KINDO_API_KEY
});

const response = await client.chat.completions.create({
  model: 'claude-sonnet-4-5-20250929',
  messages: [
    { role: 'user', content: 'Explain Kubernetes pod security policies.' }
  ]
});

console.log(response.choices[0].message.content);
```

## curl

```bash
curl -X POST https://api.kindo.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "model": "claude-sonnet-4-5-20250929",
    "messages": [
      { "role": "user", "content": "Explain Kubernetes pod security policies." }
    ]
  }'
```

## Response shape

```json
{
  "id": "chatcmpl-abc123",
  "object": "chat.completion",
  "created": 1710000000,
  "model": "claude-sonnet-4-5-20250929",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Pod Security Policies were Kubernetes rules..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 24,
    "completion_tokens": 134,
    "total_tokens": 158
  }
}
```

## What you get by default

- A single-shot, **stateless** completion. No persistence, no
  conversation linkage.
- Your `messages` flow through verbatim. Kindo does **not** prepend
  a curated system prompt.
- Tools are **only** what you list in `tools`. Kindo does not
  silently inject hosted tools.

Kindo's opt-in extensions (curated system prompt, hosted tools,
stateful conversations) are available on `/v1/responses`. See the
[Chat Actions guide](/guides/chat-actions/) for that surface.

## Migrating from `llm.kindo.ai`

`llm.kindo.ai` is deprecated. Change the subdomain:

```python
# Old
client = OpenAI(base_url="https://llm.kindo.ai", api_key="...")

# New
client = OpenAI(base_url="https://api.kindo.ai/v1", api_key="...")
```

The request and response bodies are identical. If you previously
sent the bare `api-key:` header, use `Authorization: Bearer`
for `api.kindo.ai`.

## Next steps

- [Request shape](/apis/chat-completions/request-shape/) — every standard field Kindo
  honors.
- [Streaming](/apis/chat-completions/streaming/) — `stream: true` and SSE.
- [Tool use](/apis/chat-completions/tool-use/) — function-calling round trip.
- [Errors](/apis/chat-completions/errors/) — error envelope shapes.

---

## Control plane endpoints

Source: https://docs.kindo.ai/apis/control-plane/

Beyond the inference protocols, Kindo exposes a small set of
**control-plane** endpoints on `api.kindo.ai` for inspecting and
configuring the platform's models, integrations, and default
connections. They use the same `Authorization: Bearer $KINDO_API_KEY`
auth as the inference surfaces.

`GET /v1/models` speaks the
[OpenAI Models API](https://platform.openai.com/docs/api-reference/models)
verbatim — stock OpenAI clients work unmodified. The integration
endpoints below are Kindo-specific.

## Models

### `GET /v1/models`

Speaks the OpenAI Models API. The response shape is identical to
`GET https://api.openai.com/v1/models`, so any stock OpenAI client
(`openai-python`, `openai-node`, `client.models.list()` in the SDKs,
`curl`, etc.) works against `https://api.kindo.ai/v1/models`
unmodified — just swap the base URL and key. The IDs returned here
are the exact strings to pass as `model` on `/v1/chat/completions`,
`/v1/responses`, and `/v1/messages`.

```bash
curl https://api.kindo.ai/v1/models \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

```json
{
  "object": "list",
  "data": [
    {
      "id": "claude-sonnet-4-5-20250929",
      "object": "model",
      "created": 0,
      "owned_by": "kindo"
    }
  ]
}
```

For full detail on naming conventions, cross-API model use, and
discovery via the Kindo Terminal, see the
[Model catalog](/overview/model-catalog/) page.

## Integration connections

The Integrations API lets you list integration connections accessible
to the API-key holder and pick the preferred (default) connection for
each integration. Connections are managed through the Kindo Terminal;
this API exposes the read view plus the default-setter.

### `GET /v1/integrations/connections`

Returns every connection the caller can see, including shared group
connections. Each entry indicates whether it is the preferred default
for that integration.

```bash
curl https://api.kindo.ai/v1/integrations/connections \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

```json
{
  "data": [
    {
      "id": "conn_abc123",
      "display_name": "Charlie's Linear",
      "integration_config_id": "linear",
      "nango_connection_id": "nango_conn_1",
      "is_preferred": true,
      "created_at": "2026-03-10T18:45:23.000Z"
    }
  ]
}
```

| Field                   | Type    | Notes                                                                                                            |
| ----------------------- | ------- | ---------------------------------------------------------------------------------------------------------------- |
| `id`                    | string  | Connection ID. Pass this as `connection_id` when setting a default.                                              |
| `display_name`          | string  | Display name from the Kindo Terminal.                                                                            |
| `integration_config_id` | string  | The `nangoIntegrationId` (e.g. `linear`, `github`). Same value used as `{integration_id}` in the default-setter. |
| `nango_connection_id`   | string  | Upstream Nango connection ID.                                                                                    |
| `is_preferred`          | boolean | `true` when this connection is the preferred default for `integration_config_id`.                                |
| `created_at`            | string  | ISO-8601 timestamp.                                                                                              |

### `POST /v1/integrations/connections/{integration_id}/default`

Sets the preferred connection for the given integration. The
`{integration_id}` path segment is the same value as
`integration_config_id` returned by the list endpoint — both refer to
the `nangoIntegrationId`.

```bash
curl -X POST https://api.kindo.ai/v1/integrations/connections/linear/default \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{ "connection_id": "conn_abc123" }'
```

Response:

```json
{
  "integration_config_id": "linear",
  "connection_id": "conn_abc123"
}
```

Errors:

| Status | Cause                                                                                               |
| ------ | --------------------------------------------------------------------------------------------------- |
| `400`  | Invalid body — `connection_id` is required, or `connection_id` does not belong to `integration_id`. |
| `403`  | The key authenticated, but is not authorized to use the specified connection.                       |
| `404`  | The integration connection was not found, or the caller does not have access to it.                 |

## See also

- [Model catalog](/overview/model-catalog/) — naming conventions and
  cross-API model use.
- [Agents API](/apis/agents/quickstart/) — discover and trigger
  agents that route through the models exposed here.
- [MCP API](/apis/mcp/quickstart/) — invoke tools from the same
  integration connections through Kindo's MCP gateway.

---

## Conversations API quickstart

Source: https://docs.kindo.ai/apis/conversations/quickstart/

`GET https://api.kindo.ai/v1/conversations/{conversation_id}/items`
speaks the OpenAI
[Conversations API](https://platform.openai.com/docs/api-reference/conversations).
Stock OpenAI clients work unmodified.

The Conversations API is a **read-only** view into the items that
make up a Kindo-managed conversation. It's the companion to
`/v1/responses` when you run with `store: true` (or supply
`conversation`) and want to fetch the persisted history server-side
rather than re-reading it from your own application state.

Two endpoints:

- `GET /v1/conversations/{conversation_id}/items` — list every item
  in a conversation (messages, reasoning, tool calls, tool results).
- `GET /v1/conversations/{conversation_id}/items/{item_id}` — fetch
  one item.

## Prerequisites

- A Kindo API key (see [Authentication](/overview/authentication/)).
- A `conversation_id`. The two common ways to get one:
  - The `response.conversation.id` field returned by a
    [`POST /v1/responses`](/apis/responses/quickstart/) call with
    `store: true`.
  - The Kindo Terminal exposes conversation IDs in the agent /
    chat-actions view.

## List the items in a conversation

```bash
curl https://api.kindo.ai/v1/conversations/conv_abc123/items \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

Response:

```json
{
  "object": "list",
  "data": [
    {
      "id": "msg_xyz789",
      "type": "message",
      "role": "user",
      "content": [
        { "type": "input_text", "text": "What is the capital of France?" }
      ],
      "status": "completed"
    },
    {
      "id": "msg_xyz790",
      "type": "message",
      "role": "assistant",
      "content": [
        { "type": "output_text", "text": "The capital of France is Paris." }
      ],
      "status": "completed"
    }
  ],
  "has_more": false,
  "first_id": "msg_xyz789",
  "last_id": "msg_xyz790"
}
```

`has_more`, `first_id`, and `last_id` are always present on the list
response. Pass `last_id` as `?after=` to fetch the next page; see
[Request shape](/apis/conversations/request-shape/#query-parameters) for `limit`,
`order`, and `after`.

A single assistant turn can produce **multiple top-level items** in
`data` — for example a `function_call` (tool use) followed by a
`message` are emitted as siblings, not nested. Treat the response as
a flat ordered stream and dispatch on each item's `type`.

## Fetch a single item

```bash
curl https://api.kindo.ai/v1/conversations/conv_abc123/items/msg_xyz789 \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

The response object matches a single entry from `data[]` on the list
call.

## When to use this surface

- **Auditing** — replay the exact items the model saw, in order,
  after a run finished.
- **Resuming UI state** — fetch a conversation on page load instead
  of caching it client-side.
- **Tool-call analysis** — inspect every `function_call` and
  `function_call_output` pair that the model emitted.

`Conversations` is read-only. To **continue** a stored conversation,
send a new `POST /v1/responses` with `conversation: "conv_..."` —
see [Responses → Chat Actions extensions](/apis/responses/kindo-extensions/#3-stateful-conversations).

## Next steps

- [Request shape](/apis/conversations/request-shape/) — query parameters, response
  shape, and item types.
- [Errors](/apis/conversations/errors/) — the OpenAI-style nested envelope and the
  `(type, code)` pairs Conversations returns.

---

## MCP API quickstart

Source: https://docs.kindo.ai/apis/mcp/quickstart/

Connect any MCP client to Kindo and access permitted tools from connected
integrations and first-party Platform tools through one URL with one API key.
Tools are available only when your organization's approval setting is
**Run automatically**. An organization setting of **Ask before running** or **Block**
hides tools and prevents external MCP execution. Personal tool approval settings
apply to Kindo chats and agents; configure your tool preferences in your external
client. For tools requiring approval, use Kindo chat if manual approvals are
enabled for your organization, or contact your administrator.

`POST https://api.kindo.ai/v1/mcp` is a remote Model Context
Protocol server. Point a spec-conformant MCP client at it and you
get a tool catalog filtered by your account's access and organization approval settings.
A typical `tools/list` will return entries like:

- `linear_create_issue`
- `github_search_repositories`
- `slack_post_message`
- `jira_get_ticket`
- `notion_search_pages`

Integration tools are prefixed with their integration ID. First-party Platform
tools use the `platform_` prefix and require Platform MCP to be configured.
Discovery applies [tool availability and policy checks](/apis/mcp/scoping/).
Calls also check current access and permission for the requested resource;
appearing in the catalog does not guarantee that every call is permitted.

## Prerequisites

- A Kindo API key (see [Authentication](/overview/authentication/)).
- An MCP-capable client. Anything that speaks the MCP spec works —
  Claude Code, OpenClaw, Codex CLI, Claude Desktop, Hermes, Cursor, VS Code,
  or your own code using the official SDK. See
  [Client setup](/apis/mcp/clients/) for copy-paste recipes.

## First call

The smallest possible end-to-end example is a raw `tools/list`
with `curl`:

```bash
curl -X POST https://api.kindo.ai/v1/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/list",
    "id": 1
  }'
```

The `Accept: application/json, text/event-stream` header is
required by the MCP Streamable HTTP transport. MCP SDKs and the
`mcp-remote` bridge set it for you; raw `curl` callers must
include it.

You'll get back the tools permitted by your organization's discovery and
automatic-execution policies, across connected integrations and first-party
Platform tools.

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "linear_list_issues",
        "description": "List issues in a Linear team",
        "inputSchema": { "type": "object", "properties": { "teamId": { "type": "string" } }, "required": ["teamId"] }
      }
    ]
  }
}
```

For department and member tools, see the [Platform tool catalog](/reference/tool-catalog/#platform-tools) for availability, limits, and bulk-assignment behavior.

## Next steps

- [Client setup](/apis/mcp/clients/) — copy-paste recipes for Claude
  Code, OpenClaw, Codex CLI, Claude Desktop, Hermes, Cursor, VS
  Code, and the JS/TS SDK.
- [Request shape](/apis/mcp/request-shape/) — required headers, supported
  JSON-RPC methods, and the tool naming convention.
- [Scoping](/apis/mcp/scoping/) — which tools you see in `tools/list`, why
  the list is what it is, and how to narrow it.

---

## Messages API quickstart

Source: https://docs.kindo.ai/apis/messages/quickstart/

`POST https://api.kindo.ai/v1/messages` speaks the Anthropic
[Messages API](https://docs.anthropic.com/en/api/messages). Stock
Anthropic clients work unmodified.

## Prerequisites

- A Kindo API key (see [Authentication](/overview/authentication/)).
- A model ID from [`GET /v1/models`](/overview/model-catalog/) —
  for example, `claude-sonnet-4-5-20250929`.

## Claude Code

Point Claude Code at Kindo with two environment variables:

```bash
export ANTHROPIC_BASE_URL=https://api.kindo.ai
export ANTHROPIC_API_KEY=$KINDO_API_KEY

claude
```

Claude Code sends standard Anthropic Messages requests to
`https://api.kindo.ai/v1/messages`. Kindo also forwards the
`x-claude-code-session-id` header for upstream session continuity.

## Anthropic Python SDK

```python

from anthropic import Anthropic

client = Anthropic(
    base_url="https://api.kindo.ai",
    api_key=os.environ["KINDO_API_KEY"],
)

message = client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=512,
    messages=[
        {"role": "user", "content": "Explain Kubernetes pod security policies."}
    ],
)

print(message.content[0].text)
```

## Anthropic TypeScript SDK

```ts

const client = new Anthropic({
  baseURL: 'https://api.kindo.ai',
  apiKey: process.env.KINDO_API_KEY
});

const message = await client.messages.create({
  model: 'claude-sonnet-4-5-20250929',
  max_tokens: 512,
  messages: [
    { role: 'user', content: 'Explain Kubernetes pod security policies.' }
  ]
});

console.log(message.content[0].text);
```

## curl

```bash
curl -X POST https://api.kindo.ai/v1/messages \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-4-5-20250929",
    "max_tokens": 512,
    "messages": [
      { "role": "user", "content": "Explain Kubernetes pod security policies." }
    ]
  }'
```

The Anthropic SDKs set `anthropic-version` for you. Raw HTTP
clients should include it.

## Response shape

```json
{
  "id": "msg_01Aq9w938a90dw8q",
  "type": "message",
  "role": "assistant",
  "model": "claude-sonnet-4-5-20250929",
  "content": [
    { "type": "text", "text": "Pod Security Policies were Kubernetes rules..." }
  ],
  "stop_reason": "end_turn",
  "stop_sequence": null,
  "usage": {
    "input_tokens": 24,
    "output_tokens": 134
  }
}
```

## What you get by default

- A single-shot, **stateless** response. No persistence.
- Your `system` and `messages` flow through verbatim. Kindo does
  **not** prepend a curated system prompt.
- Tools are **only** what you list in `tools`. Kindo does not
  silently inject hosted tools.

Kindo's opt-in extensions (curated system prompt, hosted tools,
stateful conversations) are available on `/v1/responses`. See the
[Chat Actions guide](/guides/chat-actions/) for that surface.

## Why route Claude Code through Kindo

- **Centralized governance** — same auth, model access, audit, DLP,
  and metering as your other Kindo APIs.
- **One API key** — the same Kindo key works for `/v1/messages`,
  `/v1/responses`, and `/v1/chat/completions`.
- **Model consistency** — Claude Code uses the model IDs your
  organization exposes through Kindo.

If Claude Code returns a model-not-found error, hit
`GET /v1/models` first and use one of the IDs available to your
organization.

## Next steps

- [Request shape](/apis/messages/request-shape/) — every standard field Kindo
  honors.
- [Streaming](/apis/messages/streaming/) — Anthropic's SSE event types.
- [Tool use](/apis/messages/tool-use/) — `tool_use` / `tool_result` round trip.
- [Errors](/apis/messages/errors/) — Anthropic error envelope.

---

## Responses API quickstart

Source: https://docs.kindo.ai/apis/responses/quickstart/

`POST https://api.kindo.ai/v1/responses` speaks the OpenAI
[Responses API](https://platform.openai.com/docs/api-reference/responses).
Stock OpenAI clients work unmodified. Pick the section below that
matches the client you already use.

## Prerequisites

- A Kindo API key (see [Authentication](/overview/authentication/)).
- A model ID from [`GET /v1/models`](/overview/model-catalog/) — for
  example, `claude-sonnet-4-5-20250929`.

## codex

`codex` is the OpenAI CLI built on the Responses API. Point it at
Kindo with two environment variables:

```bash
export OPENAI_BASE_URL=https://api.kindo.ai/v1
export OPENAI_API_KEY=$KINDO_API_KEY

codex
```

That's the entire integration. `codex` builds standard Responses
requests and Kindo handles them with stock OpenAI semantics.

## openai-python

```python

from openai import OpenAI

client = OpenAI(
    base_url="https://api.kindo.ai/v1",
    api_key=os.environ["KINDO_API_KEY"],
)

response = client.responses.create(
    model="claude-sonnet-4-5-20250929",
    input="Explain Kubernetes pod security policies in plain English.",
)

print(response.output_text)
```

## openai-node

```ts

const client = new OpenAI({
  baseURL: 'https://api.kindo.ai/v1',
  apiKey: process.env.KINDO_API_KEY
});

const response = await client.responses.create({
  model: 'claude-sonnet-4-5-20250929',
  input: 'Explain Kubernetes pod security policies in plain English.'
});

console.log(response.output_text);
```

## curl

```bash
curl -X POST https://api.kindo.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "model": "claude-sonnet-4-5-20250929",
    "input": "Explain Kubernetes pod security policies in plain English."
  }'
```

## Response shape

The response uses the standard OpenAI Responses output:

```json
{
  "id": "resp_abc123",
  "object": "response",
  "status": "completed",
  "model": "claude-sonnet-4-5-20250929",
  "output": [
    {
      "type": "message",
      "role": "assistant",
      "content": [
        {
          "type": "output_text",
          "text": "Pod Security Policies were Kubernetes rules that controlled what a pod was allowed to do..."
        }
      ],
      "status": "completed"
    }
  ],
  "output_text": "Pod Security Policies were Kubernetes rules that controlled what a pod was allowed to do..."
}
```

Raw HTTP responses also include `output_text` at the top level — the
SDK exposes it via a convenience field of the same name.

## What you get by default

- A single-shot, **stateless** completion. Nothing is persisted on
  Kindo's side. To carry state across calls, opt in via `store: true`,
  `conversation`, or `previous_response_id`.
- Your `instructions` (or `input`-array `developer` / `system`
  messages) flow through verbatim. Kindo does **not** prepend its
  curated system prompt.
- Tools are **only** what you list in `tools`. Kindo does not
  silently inject `kindo_shell`, `kindo_web_search`, or anything
  else.

If you want any of those — stateful conversations, a curated Kindo
system prompt, or the Kindo-hosted tool catalog — opt in via the
[Chat Actions extensions](/apis/responses/kindo-extensions/).

## Next steps

- [Request shape](/apis/responses/request-shape/) — every standard Responses field
  Kindo honors and how it's forwarded.
- [Streaming](/apis/responses/streaming/) — set `stream: true` and consume SSE.
- [Tool use](/apis/responses/tool-use/) — function-calling round trip.
- [Errors](/apis/responses/errors/) — error envelope shapes.
- [Chat Actions extensions](/apis/responses/kindo-extensions/) — opt in to Kindo
  prompts, tools, and stateful conversations.
- [Invoke Kindo agents](/guides/invoke-agents-responses-api/) — run a
  stored agent by passing `model: "agent/<agent-id>"`.

---

## Prompt and Agent Configuration Management

Source: https://docs.kindo.ai/best-practices/prompt-and-agent-configuration/

Your Kindo agents — Chatbots, Workflow Agents, and Triggered Agents — are only as reliable as the prompts, instructions, knowledge files, and integration configurations behind them. As usage grows, these assets become operational infrastructure. They should be managed with the same discipline you apply to application code or business process documentation.

This guide covers practical patterns for the full lifecycle of agent configuration management: creation, organization, version control, documentation, backup, recovery, testing, and governance.

## 1. Create Effective Prompts

### Write Prompts Like Instructions for a New Team Member

A strong prompt is specific, structured, and testable. Treat agent instructions like a Standard Operating Procedure for a new hire.

**Do:**

- State the agent's role explicitly
- Define the expected output format
- Specify boundaries and constraints
- Include examples when the task is nuanced

**Avoid:**

- Vague requests like "analyze this and give me insights"
- Conflicting directives like "be thorough" and "keep it under 2 sentences"
- Embedding credentials or sensitive values directly in prompt text

### Example Prompt

```text
You are a vulnerability triage analyst for our security operations team.

ROLE:
- Analyze vulnerability scan results from CrowdStrike
- Classify each finding by severity and business impact
- Recommend remediation priority

OUTPUT FORMAT:
For each vulnerability, produce a row with these columns:
| CVE ID | Severity | Affected Asset | Business Impact | Recommended Action | Priority |

RULES:
- Only report Critical and High severity findings
- If a CVE has a known exploit in the wild, escalate Priority to "Immediate"
- If the affected asset is in the DMZ, increase Business Impact by one level
- Do not speculate about vulnerabilities not present in the scan data
```

### Structure Multi-Step Agents Deliberately

For Workflow and Triggered Agents:

- **Give each step one job.** If a step analyzes, prioritizes, writes a report, and files a ticket, it is doing too much.
- **Name steps descriptively.** "Fetch Open Vulnerabilities" is more maintainable than "Step 1".
- **Use the right step type.** Use LLM Steps for reasoning, API Action Steps for deterministic reads/writes, and Action Steps for integrated product actions.

### Use Knowledge Store Files Strategically

- Attach only files that are relevant to the agent's task
- Keep reference files current with a regular review cadence
- Prefer structured formats like Markdown, CSV, or JSON when possible

## 2. Organize Your Agent Portfolio

### Use Consistent Naming Conventions

A simple pattern works well:

```text
[Team/Domain] - [Function] - [Scope]
```

Examples:

- `SecOps - Vulnerability Triage - CrowdStrike`
- `IAM - Access Review Summary - SailPoint`
- `NetOps - Firewall Audit - Cisco FMC`
- `IT Helpdesk - Laptop Setup Guide - General`

### Use Descriptions as Real Documentation

A good description should answer:

1. What does this agent do?
2. When should someone use it?
3. What integrations does it require?
4. Who owns it?

Example:

> Performs first-order root cause analysis when a P1/P2 incident is created in ServiceNow. Requires ServiceNow and Splunk integrations. Owned by the Platform Engineering team. Last reviewed: 2026-02-15.

### Group by Function, Not by Creator

As your agent library grows, organize by business function rather than by the person who built the agent. Pair shared visibility with clear ownership.

## 3. Version Control

### Why Version Control Matters

Prompts are fragile. Small wording changes can create meaningful behavior changes. Without version history, you cannot reliably:

- Roll back a change that broke a production workflow
- Explain why a prompt was written a certain way
- Audit which version of an agent was active on a specific date
- Coordinate edits across a team

### Use Kindo's Built-In Version History

Kindo captures a version of each agent's configuration every time it is saved. Use the **Version History** panel in the agent builder to:

- Browse every prior version in a read-only viewer
- Inspect a past version's exact configuration (steps, inputs, triggers, knowledge store) without leaving the builder
- Restore the agent to a previous version after a regression
- Audit every restore via the `Agent Restored to Previous Version` event in the audit log

Restore replaces the agent's content (steps, inputs, triggers, knowledge store) with the selected version's content. Sharing and access controls are intentionally not part of version state — restoring an older version does not change who can see or edit the agent. All triggers (Integration Event, Direct Webhook, Cron) always land **inactive** after a restore and must be explicitly re-enabled, so a months-old version does not silently resume external side effects.

Opening the Version History panel, viewing a prior version, and restoring all require **`EDIT_WORKFLOW`** permission on the agent.

See [Version History](/features/creating-agents/#version-history) for the full feature reference.

### Git as a Secondary Backup

The built-in version history covers day-to-day rollback and audit needs. For an out-of-platform backup — disaster recovery, cross-org templates, or syncing agent configurations into your existing code-review and approval workflows — mirror agent configurations to Git.

A practical structure:

```text
kindo-agents/
├── README.md
├── secops/
│   └── vulnerability-triage/
│       ├── agent.yaml
│       ├── CHANGELOG.md
│       ├── DESIGN.md
│       ├── knowledge/
│       └── tests/
├── iam/
│   └── access-review/
│       ├── agent.yaml
│       └── CHANGELOG.md
└── templates/
```

### What to Capture in the Git Mirror

At minimum, track:

- Agent name and type
- Description
- Prompt / instructions
- Per-step prompts
- Model selections
- Integration dependencies
- Knowledge file references
- Trigger conditions
- Sharing and access settings (not captured by Kindo's version history)
- Owner and last-reviewed date

## 4. Documentation

### Document the "Why," Not Just the "What"

The config explains what the agent does. Documentation should explain why it was designed that way.

For business-critical agents, maintain a companion design note covering:

- Purpose
- Key design decisions
- Known limitations
- Dependencies
- Change history

### Maintain a Central Agent Catalog

For teams with many agents, keep an index like this:

| Agent                 | Type     | Owner    | Integrations | Status | Last Reviewed |
| --------------------- | -------- | -------- | ------------ | ------ | ------------- |
| Vulnerability Triage  | Trigger  | SOC Team | CrowdStrike  | Active | 2026-02-28    |
| Access Review Summary | Workflow | IAM Team | SailPoint    | Active | 2026-02-15    |
| Firewall Audit        | Workflow | NetOps   | Cisco FMC    | Draft  | —             |

## 5. Backup and Recovery

### Backup Strategy

Kindo's built-in version history is the primary recovery path for in-platform regressions. A separate Git mirror serves as a secondary backup for disaster recovery, cross-org migration, and integration with your existing code-review process.

Recommended cadence:

| Agent Criticality | Backup Frequency                             | Method                                  |
| ----------------- | -------------------------------------------- | --------------------------------------- |
| Business-critical | After every change + weekly snapshot         | Git repository                          |
| Standard          | After significant changes + monthly snapshot | Git repository or shared document store |
| Experimental      | Before promoting to production               | Git repository                          |

Back up:

- Agent configurations
- Knowledge Store files referenced by the agent
- Integration configuration details (not credentials)
- Design notes and changelogs

Do **not** store credentials, API keys, or tokens in the repo.

### Recovery Process

If an agent needs to be restored:

1. **First, try the built-in version history.** Open the agent's **Version History** panel, identify the last known good version, and select **Restore this version**. This rolls back steps, inputs, triggers, and knowledge store attachments in a single action. Note that all triggers (Integration Event, Direct Webhook, Cron) land inactive after restore — re-enable them once you've verified the restore is correct.
   - **If restore fails with a "references a deleted X" error** — the target version references a resource (secret, model, step file, integration, or knowledge-store file) that has since been deleted. Recreate the missing resource first, then retry the restore. If recreation isn't an option, fall back to the Git mirror.
2. If the version you need is no longer in Kindo's history (for example, it was pruned by retention or the agent itself was deleted), fall back to your Git mirror: recreate or update the agent in Kindo, reconnect integrations, and re-upload Knowledge Store files.
3. Run a known-good test case before returning the agent to production.
4. Document the recovery action.

The audit log records every in-platform restore as an `Agent Restored to Previous Version` event, including the source version and the resulting new version — use this for incident postmortems.

### Self-Managed Deployments

For self-managed Kindo deployments, include these in your backup strategy:

- PostgreSQL backups for agent configuration, history, and audit data
- Object storage backups for Knowledge Store files
- Secrets-manager backups and rotation procedures
- Periodic restore tests

## 6. Testing and Validation

### Build an Evaluation Habit

Before deploying an agent change:

- Run a **golden-path test** with known input and expected output
- Run **edge-case tests** for empty, malformed, or unusually large input
- Re-run golden-path tests after every prompt change to catch regressions

### Store Test Cases Alongside the Agent

```text
secops/vulnerability-triage/
├── agent.yaml
├── knowledge/
└── tests/
    ├── golden-path-input.json
    ├── golden-path-expected.md
    └── edge-case-empty-findings.json
```

## 7. Collaboration and Governance

### Establish Ownership

Every production agent should have a clearly assigned owner or owning team responsible for:

- Keeping prompts and knowledge files current
- Reviewing and approving changes
- Responding when the agent behaves unexpectedly
- Running periodic reviews

### Use Kindo's Governance Controls

Use Kindo's built-in controls intentionally:

- **RBAC** to control who can create, edit, and run agents
- **DLP filters** to reduce sensitive-data exposure
- **Audit logs** for compliance and investigation
- **Tool access controls** to limit what integrations and actions agents can use
- **Model access controls** to align capability, cost, and risk

## 8. Security Considerations

### Secrets Management

- Never embed credentials in prompt text
- Use Kindo integrations to manage external authentication
- Rotate credentials on your standard schedule

### Prompt Injection Awareness

If an agent consumes data from external systems, treat that data as untrusted input. Design prompts and tool access around defense in depth.

### Data Classification

Be intentional about what documents you attach to agents. If a Knowledge Store contains restricted data, the agent's sharing model and access settings should match that classification.

## Summary Checklist

Use this checklist when creating or reviewing an agent:

- [ ] Prompts are specific, structured, and testable
- [ ] Naming follows a consistent convention
- [ ] Description includes purpose, use case, dependencies, and owner
- [ ] Steps have clear responsibilities and names
- [ ] Knowledge files are relevant and current
- [ ] Configuration is version controlled
- [ ] Design decisions and limitations are documented
- [ ] Backups exist independently of the live environment
- [ ] Golden-path and edge-case tests exist
- [ ] Access controls match the agent's risk profile
- [ ] A person or team owns the agent
- [ ] Review cadence is defined

This guide reflects recommended practices as of May 2026 and should evolve as Kindo adds more first-class agent management capabilities.

---

## Connect to ServiceNow

Source: https://docs.kindo.ai/connecting-integrations/servicenow/

Kindo supports two integration patterns with ServiceNow:

- **OAuth 2.0 Client Credentials** — Allows Kindo to authenticate with your ServiceNow instance and access its APIs (e.g., reading and creating incidents).
- **Direct Webhook URL** — Allows ServiceNow to send real-time event notifications (e.g., incident created, updated, resolved) to a Kindo agent via an outbound webhook.

You can use either or both depending on your use case.

---

## OAuth 2.0 Client Credentials

Kindo supports integration with ServiceNow using OAuth 2.0 Client Credentials (CC) for secure authentication.

:::caution[Important]
This integration is only supported for ServiceNow instances on the **Washington DC release or newer**. Older versions of ServiceNow do not support the Client Credentials grant type for inbound OAuth, so this method will not work there. If your instance is on an older release, please contact Kindo support and we will work with you to provide an alternative authentication solution.
:::

### Prerequisites

You must have the **System Administrator** role. For certain steps, you will need to elevate your privileges to `security_admin`.

### Step 1: Enable OAuth Client Credentials Grant Type

### Step 2: Register the OAuth Application

### Next Steps

Once these steps are complete, your ServiceNow instance will be ready for integration with Kindo using OAuth 2.0 Client Credentials.

1. In Kindo, open the **Command Center** and, under **Manage Your Integrations**, connect to **ServiceNow**.
2. Enter the **Client ID** and **Client Secret** from Step 2.
3. Provide your ServiceNow instance URL (e.g., `https://<instance_id>.service-now.com`).
4. Click **Connect** to complete the integration.

If you need further assistance, please refer to [ServiceNow's documentation](https://www.servicenow.com/docs/bundle/yokohama-platform-security/page/integrate/authentication/concept/oauth-inbound.html) or contact your Kindo support representative.

---

## Direct Webhook URL

ServiceNow can send real-time event notifications to a Kindo agent using a Direct Webhook URL. When an incident (or other record) is created or updated, ServiceNow sends a POST request with the record data to your agent's webhook endpoint, triggering the agent automatically.

This is useful when you want a Kindo agent to react to ServiceNow events — for example, triaging new incidents, summarizing updates, or escalating based on priority.

### Prerequisites

- A Kindo agent with a **Direct Webhook URL** trigger saved. See [Creating Agents — Direct Webhook URL Triggers](/features/creating-agents/#direct-webhook-url-triggers) for setup instructions. Copy the generated webhook URL — you will need it in the steps below.
- **System Administrator** access to your ServiceNow instance.

### Step 1: Create an Outbound REST Message

### Step 2: Add an HTTP Method

### Step 3: Create a Business Rule

The Business Rule tells ServiceNow *when* to fire the webhook. In this example, it fires whenever an incident is created or updated.

### Step 4: Test the Integration

### Customizing the Trigger

- **Different tables**: Replace `Incident [incident]` with any ServiceNow table (e.g., Change Request, Problem, Service Request) and adjust the payload fields accordingly.
- **Conditional triggers**: Use the Business Rule's **Filter Conditions** to fire only on specific events — for example, only when priority is Critical, or only when state changes to Resolved.
- **Run conditions in Kindo**: You can also add a natural-language **Run Condition** on the Direct Webhook URL trigger in Kindo to filter which payloads actually invoke the agent. See [Creating Agents — Run Condition](/features/creating-agents/#direct-webhook-url-triggers) for details.

### Security Considerations

The Direct Webhook URL contains a cryptographically random secret token. Treat this URL as a secret — anyone who has it can trigger your agent. To rotate the token, delete the trigger in Kindo and create a new one, then update the Outbound REST Message endpoint in ServiceNow.

For more details, see [Creating Agents — Security Considerations](/features/creating-agents/#security-considerations).

---

## Chat Actions

Source: https://docs.kindo.ai/guides/chat-actions/

**Chat Actions** is Kindo's umbrella name for three orthogonal
opt-in extensions on `/v1/responses`:

1. **Curated system prompt** — let Kindo prepend its operational
   prompt.
2. **Kindo-hosted tools** — call `kindo_shell`, `kindo_web_search`,
   and the rest of the Kindo hosted-tool catalog.
3. **Stateful conversations** — let Kindo persist messages
   server-side so subsequent turns chain off them.

Each is independent. Default behavior on every API surface is
**stock provider behavior** — Kindo does not silently inject
prompts, tools, or state. You opt in explicitly, per request, when
you want Kindo's added value.

`/v1/chat/completions` and `/v1/messages` are stock OpenAI and
stock Anthropic respectively. They do not accept the Chat Actions
opt-ins; if you need the curated prompt, hosted tools, or stateful
conversations, use `/v1/responses`.

## Why Chat Actions exist

Different teams want different mixes:

- A platform team running their own agent loop wants Kindo's
  governance, but not Kindo's prompt or tools.
- An ops team running ad-hoc investigations wants the full Kindo
  agent — curated prompt, hosted tools, persistent conversation.
- A SOC team wants Kindo's tool catalog and statefulness, but their
  own carefully-tuned system prompt.

Bundling these three concerns into a single mode switch (the old
`tools: [{type: "kindo_tools"}]` sentinel) collapses the space. Chat
Actions splits them apart so each request expresses exactly what it
wants.

## How it looks on `/v1/responses`

| Concern                       | Field                                        |
| ----------------------------- | -------------------------------------------- |
| **Curated system prompt**     | `kindo.system_prompt: "agent_default"`       |
| **Hosted tools (full)**       | `tools: [{type: "kindo_tools"}]`             |
| **Hosted tools (individual)** | `tools: [{type: "kindo_shell"}, ...]`        |
| **Stateful conversation**     | `store: true` + `conversation` (spec-native) |

For the field-level spec, see
[Responses → Chat Actions extensions](/apis/responses/kindo-extensions/).

## The hosted-tool catalog

| Tool type                              | Purpose                                                             |
| -------------------------------------- | ------------------------------------------------------------------- |
| `kindo_shell`                          | Run a sandboxed shell command on a Kindo-managed agent workstation. |
| `kindo_web_search`                     | Search the web.                                                     |
| `kindo_browser_control`                | Drive a headless browser session.                                   |
| `kindo_browser_screenshot`             | Capture a screenshot of the current page.                           |
| `kindo_browser_list_network_requests`  | List network requests captured by the browser tool.                 |
| `kindo_browser_export_request_as_curl` | Export a captured request as a runnable curl command.               |
| `kindo_file_read`                      | Read a file the agent has access to.                                |
| `kindo_file_write`                     | Write to a file the agent has access to.                            |
| `kindo_file_list`                      | List files in an accessible directory.                              |
| `kindo_web_download`                   | Download a URL to the agent workspace.                              |
| `kindo_files_download_original`        | Fetch the original binary of a previously stored file.              |
| `kindo_files_download_as_text`         | Fetch a previously stored file as decoded text.                     |
| `kindo_file_share_with_user`           | Share a file with a Kindo user.                                     |
| `kindo_vpn_connect`                    | Connect the agent's network egress to an organization VPN.          |
| `kindo_vpn_disconnect`                 | Disconnect from the organization VPN.                               |
| `kindo_dashboard_generate`             | Generate a Kindo dashboard.                                         |
| `kindo_dashboard_update`               | Update a Kindo dashboard.                                           |
| `kindo_knowledge_store_search`         | Search a Kindo knowledge store.                                     |

Tool types not in this list are forwarded verbatim, so new types
work as soon as they're hosted.

## The four common combinations

All examples below are `/v1/responses` requests.

### A. Stock provider behavior (default)

Send no Chat Actions opt-ins. You get exactly what calling OpenAI
directly would give you, plus Kindo's governance.

### B. "I want Kindo's tools, but my own prompt"

```json
{
  "tools": [{ "type": "kindo_tools" }]
}
```

Hosted tools turn on; your `instructions` / `system` / `messages`
flow through verbatim.

### C. "I want Kindo's prompt and tools, but I'll manage state myself"

```json
{
  "store": true,
  "kindo": { "system_prompt": "agent_default" },
  "tools": [{ "type": "kindo_tools" }]
}
```

The API auto-creates a conversation and returns the new ID in
`conversation.id`. To stay stateless, discard that ID and do not
pass it back.

### D. "I want the full Kindo agent experience"

```json
{
  "store": true,
  "kindo": { "system_prompt": "agent_default" },
  "conversation": "conv_...",
  "tools": [{ "type": "kindo_tools" }]
}
```

## Mixing Kindo-hosted tools with stock function tools

You can mix Kindo-hosted entries (`{type: "kindo_*"}`) with stock
OpenAI function tools in the same `tools` array on `/v1/responses`.
The hosted-tool shape is uniform; the function-tool shape follows
the per-API canonical form. See
[Responses tool use](/apis/responses/tool-use/) for the
function-tool round trip.

## See also

- [Responses → Chat Actions extensions](/apis/responses/kindo-extensions/)
  — full field-level spec.
- [Responses quickstart](/apis/responses/quickstart/) — stock-OpenAI
  baseline before any extensions.

---

## Exercise A - Firewall Rule Optimizer

Source: https://docs.kindo.ai/learning/customer-training-session/exercises/firewall-rule-optimizer/

## Exercise Metadata

| Field | Value |
| --- | --- |
| Duration | ~25 minutes |
| Type | Workflow Agent |
| Focus | Prompt engineering + Knowledge Stores |

## Scenario

Your network security team exports firewall rule reports periodically. These reports contain hundreds of rules accumulated over years, many of which are outdated, overly permissive, or redundant. Manual review is time-consuming and error-prone.

## Objective

Build a Kindo Workflow Agent that ingests a firewall rule report, analyzes each rule against security best practices, and produces a structured cleanup report.

## Output Categories

| Category | Meaning | Example Indicators |
| --- | --- | --- |
| RISKY | Significant security exposure | any-to-any rules, inbound to sensitive ports |
| OVER-PERMISSIVE | Broader than necessary | allow all ports, overly broad ranges |
| UNUSED | Zero or negligible hit counts | 0 hits over 90+ days |
| REDUNDANT | Covered by another rule | traffic fully covered by higher-priority rule |
| COMPLIANT | Correctly scoped and actively used | specific source/dest, appropriate ports, healthy hit count |

## Prerequisites

- Kindo account with access to the training instance
- Sample firewall rule report: [Download sample-firewall-rules.txt](/docs/learning/sample-firewall-rules.txt)

## About the Sample Data

The sample firewall rule report contains 40 rules representing a realistic corporate firewall accumulated over several years. The rules include a deliberate mix of:

- **Clean rules** that are correctly scoped and actively used (web server access, monitoring, security tooling)
- **Risky rules** with direct internet exposure to sensitive services (SSH, RDP, MySQL open to `any`)
- **Over-permissive rules** with overly broad scope (`any`-to-`any` permits, full internal subnet access)
- **Unused rules** with zero hit counts from decommissioned projects, expired contracts, or completed engagements
- **Redundant rules** whose traffic is already covered by broader rules at higher priority

As you iterate through the prompt engineering steps below, notice how your output quality changes — not just in formatting, but in whether the agent catches subtle issues like dev-to-prod database access or guest WiFi misconfigurations.

## Step 1 - Create the Agent (3 min)

{/* Screenshot placeholder: Agents tab -> Create an Agent -> Workflow Agent selected */}

## Step 2 - Set Up the Knowledge Store (3 min)

:::tip
The Knowledge Store is the agent's reference library. Structured and focused source files produce cleaner and more consistent analysis. CSV works well here because each row is a self-contained rule with consistent columns — the model can process it systematically.
:::

{/* Screenshot placeholder: Knowledge Store panel with uploaded file visible */}

## Step 3 - Build the Analysis Prompt Iteratively (12 min)

This is the core teaching moment of the exercise. Instead of pasting a final prompt immediately, you will build it in three iterations and compare how each change affects output quality.

### Iteration 1 - Start Simple

```plaintext
Analyze the firewall rules in the knowledge store and identify which ones are risky or should be cleaned up.
```

:::note[What to observe]
Run this and look at the output critically. You will likely see:
- **Vague language** — "this rule might be concerning" instead of a concrete verdict
- **Inconsistent structure** — some rules get a paragraph, others get a sentence
- **Missing rules** — the model may skip rules it considers "fine" without telling you
- **No confidence signal** — you can't tell which findings the model is sure about versus guessing
:::

### Iteration 2 - Add Role and Structure

```plaintext
You are a senior network security engineer performing a firewall rule audit.

Analyze the firewall rule report in the knowledge store. For each rule, categorize it into exactly ONE of:
1. RISKY - Significant security exposure (e.g., any-to-any rules, inbound to sensitive ports)
2. OVER-PERMISSIVE - Broader than necessary
3. UNUSED - Zero or near-zero hit counts
4. REDUNDANT - Already covered by another rule
5. COMPLIANT - Correctly scoped, actively used, follows best practices

Output as a table with columns: Rule ID | Rule Name | Category | Recommendation
```

:::tip[Why this works]
Three changes made a big difference:
1. **Role specification** ("senior network security engineer") sets the analysis depth and vocabulary
2. **Explicit categories** constrain the model to consistent buckets instead of freeform commentary
3. **Fixed table format** makes the output readable and usable downstream

Compare this output to Iteration 1. You should see every rule accounted for and consistently categorized.
:::

### Iteration 3 - Production Prompt

```plaintext
You are a senior network security engineer performing a firewall rule audit.

TASK:
Analyze the firewall rule report in the knowledge store. For each rule, categorize it into exactly ONE of the following:

1. RISKY - Rules that create significant security exposure (e.g., any-to-any rules, inbound access to sensitive ports from untrusted sources, rules allowing dangerous protocols)
2. OVER-PERMISSIVE - Rules broader than necessary (e.g., allow all ports when specific ports would suffice, overly broad source/destination ranges)
3. UNUSED - Rules with zero or negligible hit counts during the analysis period (0 hits over 90+ days = unused; <10 hits over 90 days = near-unused)
4. REDUNDANT - Rules whose traffic is already fully covered by another rule with equal or higher priority
5. COMPLIANT - Rules that are correctly scoped, actively used, and follow security best practices (specific source/destination, appropriate ports, healthy hit counts)

ANALYSIS GUIDELINES:
- Consider source, destination, service/port, action (permit/deny), and hit count
- For RISKY: any rule allowing inbound traffic from "any" to critical infrastructure ports (22, 3389, 1433, 3306, 5432) should be flagged
- For OVER-PERMISSIVE: compare against the principle of least privilege
- If a rule could belong to multiple categories, choose the highest-risk category

OUTPUT FORMAT:
| Rule ID | Rule Name | Category | Confidence | Risk Level | Recommendation |

CONFIDENCE LEVELS:
- HIGH - Clear indicators support the categorization
- MEDIUM - Some ambiguity but categorization is likely correct
- LOW - Insufficient data; manual review recommended

After the table, provide:
1. Summary count of rules per category
2. Top 5 highest-priority rules to remediate immediately
3. Recommended next steps
```

:::note[Key learning]
Compare this output to Iteration 2. The improvements come from:
- **Explicit thresholds** (hit count numbers, specific port lists) remove ambiguity
- **Analysis guidelines** tell the model *how* to evaluate, not just *what* to look for
- **Confidence levels** support triage decisions — auto-remediate HIGH confidence findings, manually review LOW confidence ones
- **Structured follow-up sections** make the output actionable for a security operations manager

Every constraint you add improves actionability. This is the core prompt engineering lesson: precision in, precision out.
:::

## Step 4 - Add the Report Formatting Step (5 min)

Add a second LLM step named `Format Cleanup Report`.

:::tip[Why a second step?]
Separating analysis from formatting is a key workflow pattern. The first step focuses on *accuracy* (getting the categorization right). The second step focuses on *presentation* (making it useful for a specific audience). This separation also lets you swap the formatting step for different audiences — executive summary, CSV export, or Jira ticket templates — without re-running the analysis.
:::

```plaintext
You are formatting the firewall rule analysis into an executive-ready cleanup report.

Take the categorized rule analysis from the previous step and produce:

SECTION 1 - EXECUTIVE SUMMARY
- Total rules analyzed, breakdown by category (count and percentage)
- Overall risk assessment (Critical / High / Medium / Low)
- Estimated effort to remediate

SECTION 2 - IMMEDIATE ACTION ITEMS
Top 10 highest-priority rules, sorted by risk:
- Rule ID and name
- Why it's flagged
- Recommended action (remove, tighten, merge, review)
- Estimated impact if left unaddressed

SECTION 3 - CATEGORY DETAIL
For each category, list all rules sorted by confidence level (HIGH first).

SECTION 4 - RECOMMENDATIONS
- Quick wins (high confidence, low effort)
- Rules requiring manual review (low confidence)
- Suggested review cadence going forward
- Integration recommendations (e.g., connect to CrowdStrike for threat-informed prioritization)

Keep the tone professional and direct. This report goes to the security operations manager.
```

## Step 5 - Run and Review (5 min)

### Quality Checklist

- **Categorization accuracy:** categories align with the underlying rule evidence (e.g., FW-019 MySQL from `any` should be RISKY, not just OVER-PERMISSIVE)
- **Confidence calibration:** HIGH items are clearly supported, LOW items are truly ambiguous
- **Executive utility:** summary is actionable without reading every row
- **Recommendation specificity:** concrete next actions instead of generic language like "review this rule"
- **Completeness:** all 40 rules are accounted for — none silently skipped

### Iterations to Try

- Lower the `UNUSED` threshold and compare volume shifts
- Add a new category such as `EXPIRED` for rules past a decommission date
- Request output as JSON or CSV instead of markdown table
- Upload a second file (a network security policy document) to the Knowledge Store and see if the agent references it during analysis

## What You Learned

| Concept | Where You Used It |
| --- | --- |
| **Knowledge Stores** | Uploaded the firewall CSV as a reference for analysis |
| **Prompt engineering** | Iterated from vague to production-quality through three versions |
| **Role specification** | Set the model's expertise level and vocabulary |
| **Output structuring** | Controlled format with explicit tables, categories, and sections |
| **Confidence levels** | Added calibration signals for downstream triage |
| **Multi-step workflows** | Separated analysis from formatting for reusability |

## Discussion Points

- Which prompt iteration had the biggest impact on output quality, and why?
- What additional guardrails are needed before using this in production?
- Where could you connect ticketing or trigger automation to close the loop (e.g., auto-create a Jira ticket for each RISKY rule)?
- How would you adapt this pattern for a different security domain — vulnerability scan results, IAM policy reviews, or cloud security posture?

## Troubleshooting

| Issue | Likely Cause | How To Fix |
| --- | --- | --- |
| Output is vague and inconsistent | Prompt lacks role, constraints, and schema | Move from Iteration 1 to Iteration 3 prompt structure |
| Most rules marked as RISKY | Categories are underspecified or rule data is sparse | Add explicit category definitions and confidence rules |
| Missing rules in output | Model hit context limits or skipped rows | Ask for chunked analysis (for example, 100 rules at a time) and merge results |
| Confidence levels all HIGH | Prompt does not define evidence standards | Keep the explicit HIGH/MEDIUM/LOW criteria block |
| Recommendations are generic | Formatting step not included | Add Step 4 report formatter and require prioritized actions |

## Next Exercise

Continue to [Exercise B - Universal Security Triage Agent](/learning/customer-training-session/exercises/universal-triage-agent/).

---

## Getting started

Source: https://docs.kindo.ai/overview/getting-started/

Kindo exposes industry-standard inference protocols on a single base
URL — `https://api.kindo.ai` — authenticated by a single Kindo API
key. Bring whichever client you already use, point it at
`api.kindo.ai`, and the rest of your code works unmodified.

## Common inference endpoints

| Endpoint               | Protocol                | Use it when                                                                             |
| ---------------------- | ----------------------- | --------------------------------------------------------------------------------------- |
| `/v1/chat/completions` | OpenAI Chat Completions | You're migrating from OpenAI's Chat Completions API or any OpenAI-compatible proxy.     |
| `/v1/responses`        | OpenAI Responses        | You're using `codex`, the new OpenAI Responses surface, or want stateful conversations. |
| `/v1/messages`         | Anthropic Messages      | You're using Claude Code, the Anthropic SDK, or any Anthropic-compatible client.        |
| `/v1/mcp`              | Model Context Protocol  | You want an MCP client to reach [permitted tools across Kindo integrations](/apis/mcp/scoping/). |

All of these accept the **same Kindo API key** — there are no
per-protocol credentials. The only difference between using Kindo and
calling OpenAI or Anthropic directly is which base URL you point your
client at and which key you use.

Beyond the inference protocols, Kindo also exposes control-plane
endpoints for agents, runs, conversations, models, and integrations
— see the **APIs** sidebar for the full list, or jump to:

- [Agents API](/apis/agents/quickstart/) — discover, trigger, and
  poll agent runs.
- [Conversations API](/apis/conversations/quickstart/) — read items
  from a stored conversation.
- [Control-plane endpoints](/apis/control-plane/) — `GET /v1/models`
  and `/v1/integrations/*`.

## Pick your client

Kindo follows the upstream specs faithfully. If your client speaks
the protocol, it works:

| If you use…              | Set this base URL                                    | Set this key envvar                              | API surface                                      |
| ------------------------ | ---------------------------------------------------- | ------------------------------------------------ | ------------------------------------------------ |
| `codex`                  | `OPENAI_BASE_URL=https://api.kindo.ai/v1`            | `OPENAI_API_KEY=$KINDO_API_KEY`                  | `/v1/responses`                                  |
| `openai-python`          | `OpenAI(base_url="https://api.kindo.ai/v1")`         | `OpenAI(api_key=os.environ["KINDO_API_KEY"])`    | `/v1/chat/completions` (or `client.responses.*`) |
| `openai-node`            | `new OpenAI({ baseURL: "https://api.kindo.ai/v1" })` | `apiKey: process.env.KINDO_API_KEY`              | `/v1/chat/completions` (or `client.responses.*`) |
| Anthropic Python SDK     | `Anthropic(base_url="https://api.kindo.ai")`         | `Anthropic(api_key=os.environ["KINDO_API_KEY"])` | `/v1/messages`                                   |
| Anthropic TypeScript SDK | `new Anthropic({ baseURL: "https://api.kindo.ai" })` | `apiKey: process.env.KINDO_API_KEY`              | `/v1/messages`                                   |
| Claude Code              | `ANTHROPIC_BASE_URL=https://api.kindo.ai`            | `ANTHROPIC_API_KEY=$KINDO_API_KEY`               | `/v1/messages`                                   |
| MCP client (spec-conformant) | `https://api.kindo.ai/v1/mcp`                    | `Authorization: Bearer $KINDO_API_KEY`           | `/v1/mcp`                                        |
| Raw `curl`               | `https://api.kindo.ai`                               | `Authorization: Bearer $KINDO_API_KEY`           | Any of the above                                 |

The Anthropic SDKs and Claude Code append `/v1/messages`
internally, so the base URL omits `/v1`. Including it would produce a
double path segment (`/v1/v1/messages`).

## Why one base URL, many protocols

Different teams standardize on different SDKs, and each protocol has
different ergonomics: Chat Completions is the broadly-supported
baseline, the Responses API adds stateful conversations and
typed-output items, Messages is what Anthropic's first-party tools
speak, MCP is what spec-conformant tool-calling clients speak. By
accepting all of them on one base URL with one API key, Kindo lets
every team keep its existing client choice while still routing
through a single governance pipeline (auth, model access, audit, DLP,
metering).

## Default behavior is stock provider behavior

When you call `/v1/chat/completions`, `/v1/responses`, or
`/v1/messages` with a stock OpenAI or Anthropic client, you get
**stock OpenAI or Anthropic semantics**. Kindo does not silently
inject system prompts, hidden tools, or stateful side effects.

If you want any of those things on `/v1/responses`, opt in
explicitly via the **Chat Actions** extensions: a curated system
prompt, the Kindo-hosted tool catalog, and Kindo-managed
conversation state. Each is independent and documented at
[guides/chat-actions](/guides/chat-actions/). `/v1/chat/completions`
and `/v1/messages` are stock OpenAI and stock Anthropic; the Chat
Actions opt-ins are not available there.

## Next steps

- [Authentication](/overview/authentication/) — header options and
  key formats.
- [Model catalog](/overview/model-catalog/) — discover what model
  IDs to send.
- Pick a quickstart:
  - [Responses API quickstart](/apis/responses/quickstart/) for
    `codex` and the OpenAI Responses SDK.
  - [Chat Completions API quickstart](/apis/chat-completions/quickstart/)
    for `openai-python` / `openai-node`.
  - [Messages API quickstart](/apis/messages/quickstart/) for Claude
    Code and the Anthropic SDKs.
  - [MCP API quickstart](/apis/mcp/quickstart/) for any
    spec-conformant MCP client.
  - [Agents API quickstart](/apis/agents/quickstart/) for triggering
    Kindo agents over HTTP.
- [Chat Actions](/guides/chat-actions/) — opt in to Kindo's curated
  prompt, hosted tools, or stateful conversations on `/v1/responses`.

---

## Agents API request shape

Source: https://docs.kindo.ai/apis/agents/request-shape/

The Agents API is composed of two discovery endpoints, one trigger
endpoint, and two run-inspection endpoints covered in
[Runs](/apis/agents/runs/). All responses are JSON. Authentication is the same
`Authorization: Bearer $KINDO_API_KEY` used elsewhere.

## `GET /v1/agents/list`

Lists agents the API-key holder can see. This endpoint accepts no
query parameters and returns the visible agents in a single page,
capped at 500 entries. The response does not include a `has_more`
or cursor field; callers that need more than 500 agents in a single
organization should reach out to Kindo.

```bash
curl https://api.kindo.ai/v1/agents/list \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

Response:

```json
{
  "items": [
    {
      "agentId": "18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d",
      "name": "Daily Security Scan",
      "description": "Runs the daily vulnerability check workflow.",
      "createdAt": "2026-03-10T18:45:23.000Z",
      "creatorName": "Security Team",
      "metadata": { "userPermissions": ["view", "edit"] }
    }
  ],
  "total": 1
}
```

Envelope:

| Field   | Type    | Notes                                                                                                                                          |
| ------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `items` | array   | One entry per accessible agent. See the item-shape table below.                                                                                |
| `total` | integer | Always equal to `items.length`. This endpoint is non-paginated; `total` is a convenience field, not a counter. Capped at 500 — see note above. |

Item shape:

| Field         | Type   | Notes                                                                                                                                              |
| ------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| `agentId`     | string | UUID. Use it in `/v1/agents/{agentId}` and `runs` calls.                                                                                           |
| `name`        | string | Display name from the Kindo Terminal.                                                                                                              |
| `description` | string | Free-form description.                                                                                                                             |
| `createdAt`   | string | ISO-8601 timestamp.                                                                                                                                |
| `creatorName` | string | Name of the user or group that created the agent.                                                                                                  |
| `metadata`    | object | `{ "userPermissions": string[] }`. Entries are the actions the caller may perform on this agent — any subset of `view`, `edit`, `delete`, `share`. |

## `GET /v1/agents/{agentId}`

Returns the full agent configuration, including the `inputs` label
list you must match when triggering a run. Optional query
parameters paginate and filter the `recentRunIds` list.

```bash
curl https://api.kindo.ai/v1/agents/18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

Query parameters (all optional):

| Parameter   | Type    | Notes                                                                                                                                                                                                       |
| ----------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `limit`     | integer | Maximum number of run IDs to return in `recentRunIds`. Integer between `1` and `100` (inclusive). Defaults to `20` when any pagination/filter query parameter is supplied.                                  |
| `cursor`    | string  | Opaque pagination cursor returned in `nextCursor` on the previous response. Pass it back unchanged to fetch the next page. The encoding is internal and may change — do not parse, modify, or construct cursors yourself. When combined with `startDate`/`endDate`, re-pass the same date filters on every follow-up request; the cursor does not encode them.                                                          |
| `startDate` | string  | Inclusive ISO-8601 lower bound; only runs created at or after this timestamp are returned in `recentRunIds`.                                                                                                |
| `endDate`   | string  | Inclusive ISO-8601 upper bound; only runs created at or before this timestamp are returned in `recentRunIds`. When both are supplied, `startDate` must be less than or equal to `endDate`.                  |

When no query parameters are supplied, the response shape and legacy
run cap are preserved (up to 5 `recentRunIds`, no `nextCursor` field).
When any of `limit`, `cursor`, `startDate`, or `endDate` is supplied,
the paginated path is used: omitted `limit` defaults to `20`, and the
response always includes a `nextCursor` field, which is `null` on the
last page.

Response:

```json
{
  "agentId": "18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d",
  "name": "Daily Security Scan",
  "description": "Runs the daily vulnerability check workflow.",
  "inputs": ["query"],
  "hasTriggers": false,
  "modelsInUse": ["claude-sonnet-4-5-20250929"],
  "recentRunIds": ["7a7ced7d-95a8-416f-95bb-5c0ff3599f53"],
  "lastRunAtUtc": "2026-03-12T15:00:00.000Z",
  "metadata": { "userPermissions": ["view", "edit"] }
}
```

| Field          | Type             | Notes                                                                                                                                                                 |
| -------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `agentId`      | string           | UUID.                                                                                                                                                                 |
| `name`         | string           | Display name.                                                                                                                                                         |
| `description`  | string           | Free-form description.                                                                                                                                                |
| `inputs`       | array of strings | Each entry is the label the agent expects in `POST /v1/agents/runs`. Returned in ascending alphabetical order, not in agent-configuration order.                      |
| `hasTriggers`  | boolean          | `true` when the agent has scheduled, event, or webhook triggers configured. Informational — a trigger is an additional way the agent starts and does not prevent running it via `POST /v1/agents/runs`.                                        |
| `modelsInUse`  | array of strings | Model IDs this agent currently routes through.                                                                                                                        |
| `recentRunIds` | array of strings | Run IDs ordered newest-first. With no query parameters, capped by the legacy default of 5. With pagination/filter parameters, capped by `limit` (default 20, max 100) and filtered by `startDate`/`endDate` when supplied. |
| `lastRunAtUtc` | string \| null   | ISO-8601 timestamp of the agent's most recent run, or `null` if it has never run. Independent of `startDate`/`endDate` filters — always reflects the true latest run. |
| `nextCursor`   | string \| null   | Present only when one of `limit`, `cursor`, `startDate`, or `endDate` is supplied. A string cursor when more pages remain; `null` when the current page is the last.  |
| `metadata`     | object           | `{ "userPermissions": string[] }`. Entries are the actions the caller may perform — any subset of `view`, `edit`, `delete`, `share`.                                  |

## `POST /v1/agents/runs`

Triggers an agent execution.

```bash
curl -X POST https://api.kindo.ai/v1/agents/runs \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "agentId": "18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d",
    "inputs": [
      { "name": "query", "value": "Run the daily security scan" }
    ]
  }'
```

Request body:

| Field     | Required | Type             | Notes                                                                                                                                                                                                                                  |
| --------- | -------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `agentId` | Yes      | string           | An `agentId` returned by `GET /v1/agents/list`.                                                                                                                                                                                        |
| `inputs`  | No       | array of objects | Each entry is `{ "name": string, "value": string }`. `name` must match a label from `GET /v1/agents/{agentId}`'s `inputs`. Required labels that are omitted produce a `422`; entries with an unrecognized `name` are silently dropped. |

Response (`202 Accepted`):

```json
{
  "runId": "7a7ced7d-95a8-416f-95bb-5c0ff3599f53",
  "conversationId": "clx9a2b1c0000d4e5f6g7h8i9"
}
```

| Field            | Type   | Notes                                                                                                                                                                                          |
| ---------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `runId`          | string | UUID for the created run. Poll it via `GET /v1/runs/{runId}`.                                                                                                                                  |
| `conversationId` | string | The conversation backing the run. Pass it to `GET /v1/conversations/{conversation_id}/items` to read the message history — the basis for multi-turn continuity. Created together with the run. |

A `202` means Kindo accepted the trigger and will execute the run
asynchronously. Use [Runs](/apis/agents/runs/) to poll the result.

## See also

- [Quickstart](/apis/agents/quickstart/) — the end-to-end discover → trigger → poll → evals flow.
- [Runs](/apis/agents/runs/) — `GET /v1/runs/{runId}` shape, lifecycle, and `GET /v1/runs/{runId}/evals` step verdicts.
- [Errors](/apis/agents/errors/) — error envelopes for each endpoint.

---

## Chat Completions API request shape

Source: https://docs.kindo.ai/apis/chat-completions/request-shape/

`POST /v1/chat/completions` accepts the OpenAI Chat Completions
request body. Kindo validates the core fields and forwards the rest
verbatim, which keeps the endpoint forward-compatible with new
OpenAI request fields.

## Required fields

| Field      | Type   | Notes                                                                   |
| ---------- | ------ | ----------------------------------------------------------------------- |
| `model`    | string | A model ID from [`GET /v1/models`](/overview/model-catalog/).           |
| `messages` | array  | Must contain at least one entry. See [Messages array](#messages-array). |

## Standard fields

| Field               | Type             | Forwarded? | Notes                                                                               |
| ------------------- | ---------------- | ---------- | ----------------------------------------------------------------------------------- |
| `stream`            | boolean          | —          | Consumed by the route handler to switch into SSE mode.                              |
| `temperature`       | number           | Yes        | Sampling temperature.                                                               |
| `max_tokens`        | integer          | Yes        | Max tokens to generate.                                                             |
| `top_p`             | number           | Yes        | Nucleus sampling.                                                                   |
| `frequency_penalty` | number           | Yes        |                                                                                     |
| `presence_penalty`  | number           | Yes        |                                                                                     |
| `stop`              | string \| array  | Yes        | Stop sequences.                                                                     |
| `tools`             | array            | Yes        | OpenAI tool definitions (see [Tool use](/apis/chat-completions/tool-use/)).                              |
| `tool_choice`       | string \| object | Yes        | `"auto"`, `"none"`, `"required"`, or `{type: "function", function: {name: "..."}}`. |
| `response_format`   | object           | Yes        | E.g. `{type: "json_object"}` or `{type: "json_schema", ...}`.                       |
| `user`              | string           | Yes        | End-user identifier.                                                                |
| `seed`              | integer          | Yes        | Determinism hint, where the upstream model supports it.                             |
| `logprobs`          | boolean / object | Yes        | Forwarded to the upstream model.                                                    |

Anything not listed above passes through Kindo's schema verbatim
because the validator uses `passthrough()`. Refer to OpenAI's
[Chat Completions spec](https://platform.openai.com/docs/api-reference/chat/create)
for full field semantics.

### JSON mode

Both variants of `response_format` are accepted:

- `{"type": "json_object"}` — any JSON object.
- `{"type": "json_schema", "json_schema": {...}}` — forwarded whole,
  schema included, for models that enforce a schema.

How `{"type": "json_object"}` is enforced depends on the provider
backing the model you selected:

| Provider family                                                  | How it is enforced                                                                                                       |
| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| OpenAI-format (OpenAI, Azure OpenAI, Groq, Mistral, DeepSeek, …) | Forwarded verbatim; the provider enforces JSON mode itself.                                                              |
| Gemini                                                           | Forwarded to the provider's own JSON output mode.                                                                        |
| Claude — direct, on Vertex AI, and on Bedrock                    | Translated by Kindo, because the provider has no schemaless JSON switch. The translation is not visible in the response. |

On those, `choices[0].message.content` is raw JSON you can parse
directly, with no markdown code fence, on both streaming and
non-streaming requests.

Three cases are **not** guaranteed:

- **A provider with no JSON mode of its own** — Cohere, for example.
  `response_format` is accepted and has no effect there, so the model
  may answer in prose or wrap the JSON in a markdown code fence. Parse
  defensively if your model group can route to one of these.
- **`{"type": "json_object"}` sent together with `tools` or
  `tool_choice`.** On models without native JSON mode, Kindo will not
  suppress the tools you asked for in order to force JSON, so the
  response may be prose. Send a `json_schema`, or omit the tools, when
  you need a parseable response from that combination.
- **`{"type": "json_object"}` sent together with extended thinking
  (`thinking` or `reasoning_effort`).** Anthropic rejects the forced
  tool call that JSON mode is translated into when thinking is on, so on
  models without native JSON mode the response may be prose. Send a
  `json_schema`, or drop the reasoning parameter, when you need a
  parseable response.

### Stripped-on-ingress fields

Kindo strips these fields from the outgoing upstream request so
clients can't spoof governance metadata:

- `metadata`
- `litellm_metadata`
- `proxy_server_request`

## Messages array

Each message has the following shape:

| Field          | Required | Notes                                                                                                                                                    |
| -------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `role`         | Yes      | `system`, `developer`, `user`, `assistant`, or `tool`.                                                                                                   |
| `content`      | No       | String, array of content blocks, or `null` (for assistant messages with only `tool_calls`). Arrays are forwarded verbatim and support multimodal blocks. |
| `name`         | No       | Author name.                                                                                                                                             |
| `tool_calls`   | No       | Tool calls generated by the model (present on assistant messages).                                                                                       |
| `tool_call_id` | No       | Required on `role: "tool"` messages — the ID of the tool call this message is responding to.                                                             |

`developer` is treated identically to `system` and matches OpenAI's
own semantics.

## Kindo extension fields

`/v1/chat/completions` is stock OpenAI — Kindo does not accept a
`kindo` request block on this surface. Kindo's opt-in extensions
(curated system prompt, hosted tools, stateful conversations) are
available on `/v1/responses`; see the
[Chat Actions guide](/guides/chat-actions/).

## Worked example

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "messages": [
    { "role": "system", "content": "You are a concise security assistant." },
    { "role": "user", "content": "Summarize CVE-2024-3094." }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "lookup_cve",
        "description": "Fetch CVE metadata.",
        "parameters": {
          "type": "object",
          "properties": { "id": { "type": "string" } },
          "required": ["id"]
        }
      }
    }
  ],
  "tool_choice": "auto",
  "max_tokens": 512,
  "temperature": 0.2
}
```

This is stock OpenAI Chat Completions. Kindo accepts it identically
to OpenAI's `/v1/chat/completions`.

## See also

- [Quickstart](/apis/chat-completions/quickstart/) — minimal client setup.
- [Streaming](/apis/chat-completions/streaming/) — SSE protocol.
- [Tool use](/apis/chat-completions/tool-use/) — function-calling round trip.
- [Errors](/apis/chat-completions/errors/) — error envelope.

---

## Conversations API request shape

Source: https://docs.kindo.ai/apis/conversations/request-shape/

Both endpoints speak the OpenAI
[Conversations API](https://platform.openai.com/docs/api-reference/conversations)
verbatim, exposing the items stored when you run `/v1/responses`
with `store: true`. Both are `GET` and return JSON.

## `GET /v1/conversations/{conversation_id}/items`

Lists items in the conversation in the order they were appended.

```bash
curl https://api.kindo.ai/v1/conversations/conv_abc123/items?limit=50&order=asc \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

### Query parameters

| Name    | Type    | Default | Notes                                                                                                                                                                                                             |
| ------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `limit` | integer | `20`    | Messages per page. Range `1`–`100`. Each message may expand to multiple items (an assistant turn with a tool call produces a `function_call` plus a `message`), so the returned `data` length may exceed `limit`. |
| `order` | string  | `desc`  | `asc` or `desc`. Sort order by message index.                                                                                                                                                                     |
| `after` | string  | —       | Cursor: return items appended after this item ID. Pass `last_id` from the previous response. An item ID not present in this conversation produces `400 invalid_cursor`.                                           |

### Response

| Field      | Type           | Notes                                                               |
| ---------- | -------------- | ------------------------------------------------------------------- |
| `object`   | string         | Always `"list"`.                                                    |
| `data`     | array          | One entry per item. See [Item types](#item-types).                  |
| `has_more` | boolean        | `true` when another page is available; pass `last_id` as `?after=`. |
| `first_id` | string \| null | ID of the first item in `data`, or `null` when `data` is empty.     |
| `last_id`  | string \| null | ID of the last item in `data`, or `null` when `data` is empty.      |

### Item types

The `type` field on each item determines the rest of its shape. A
single assistant turn can produce multiple top-level items
(`function_call` siblings of `message`) — treat `data` as a flat
ordered stream rather than assuming one item per turn.

| `type`                 | Shape (key fields)                                            | Notes                                                                                                                                     |
| ---------------------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `message`              | `id`, `role`, `content[]`, `status`                           | `role` is `user`, `assistant`, or `system`. `content[]` contains typed text/image blocks.                                                 |
| `reasoning`            | `id`, `summary[]`                                             | The model's reasoning summary; `summary[]` entries are `{type: "summary_text", text}`.                                                    |
| `function_call`        | `id`, `call_id`, `name`, `arguments`                          | A model-emitted function-tool call.                                                                                                       |
| `function_call_output` | `call_id`, `output`                                           | The matching tool result (echoed back by the caller). Identified by `call_id` — `function_call_output` items do not carry their own `id`. |
| `mcp_call`             | `call_id`, `server_label`, `name`, `arguments`, `output`, `status` | A server-executed MCP tool call, with its result inline in `output` (`null` while in progress).                                      |
| `kindo_call`           | `call_id`, `name`, `arguments`, `output`, `status`            | A Kindo-hosted tool call (e.g. `kindo_web_search`), with its result inline in `output`.                                                   |
| `web_search_call`      | `call_id`, `status`                                           | A web-search invocation.                                                                                                                  |
| `shell_call`           | `call_id`, `name`, `action`, `status`                         | A sandboxed shell invocation; `action.commands` lists the commands executed.                                                              |
| `shell_call_output`    | `call_id`, `name`, `output[]`                                 | Shell results — `output[]` entries carry `stdout`, `stderr`, and an exit/timeout `outcome`.                                               |

The tool-activity and reasoning shapes are the same
[Responses output items](/apis/responses/streaming/) the model
produced them as — a conversation is the persisted transcript of
those items. Conversations backed by agent runs surface the full
step-by-step activity this way.

`message` items carry a `status` field, currently always
`"completed"` (Kindo stores items as they are persisted, not while
streaming). Items do **not** carry an `object` field — the outer
list envelope has `object: "list"`, but individual items omit it.
Dispatch on `type` instead.

Unrecognized item types are forwarded verbatim from the underlying
store, so new OpenAI Responses item shapes appear without requiring a
Kindo upgrade.

The API normalizes a `developer` role to `system` before persisting;
responses always show `system`.

## `GET /v1/conversations/{conversation_id}/items/{item_id}`

Fetches a single item. The response object matches one entry from
the `data[]` array on the list endpoint.

```bash
curl https://api.kindo.ai/v1/conversations/conv_abc123/items/msg_xyz789 \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

```json
{
  "id": "msg_xyz789",
  "type": "message",
  "role": "user",
  "content": [
    { "type": "input_text", "text": "What is the capital of France?" }
  ],
  "status": "completed"
}
```

## See also

- [Quickstart](/apis/conversations/quickstart/) — list + fetch flow.
- [Errors](/apis/conversations/errors/) — the OpenAI-style nested envelope and the
  `(type, code)` pairs returned by these endpoints.
- [Responses → Chat Actions extensions](/apis/responses/kindo-extensions/#3-stateful-conversations)
  — how a stored conversation is created and continued.

---

## MCP API — client setup

Source: https://docs.kindo.ai/apis/mcp/clients/

Every recipe below points an MCP client at `https://api.kindo.ai/v1/mcp` and authenticates with your Kindo API key in the `Authorization` header. Set `KINDO_API_KEY` in your shell, or substitute the literal value.

  

  

  

  

  

  

  

## Other clients

Any spec-conformant MCP client that supports Streamable HTTP will work. Point it at `https://api.kindo.ai/v1/mcp` and send `Authorization: Bearer YOUR_API_KEY`. If your client speaks only stdio, wrap the URL with [`mcp-remote`](https://github.com/geelen/mcp-remote) using the same pattern shown for Claude Desktop.

## Tool surface too large?

The bare endpoint shows eligible tools across the integrations your account can reach (see [Scoping](/apis/mcp/scoping/)). For broad-access accounts the catalog can exceed a model's context window. Narrow it with a query filter:

```
https://api.kindo.ai/v1/mcp?integrations=linear,github
```

The filter can only narrow what your account already admits — it never grants new access. See [`kindo-extensions`](/apis/mcp/kindo-extensions/) for the header form.

## Next steps

- [Request shape](/apis/mcp/request-shape/) — what to send, what comes back.
- [Scoping](/apis/mcp/scoping/) — which tools appear and why.
- [Errors](/apis/mcp/errors/) — auth and protocol error envelopes.

---

## Messages API request shape

Source: https://docs.kindo.ai/apis/messages/request-shape/

`POST /v1/messages` accepts the Anthropic Messages request body.
Kindo validates the core fields and forwards the rest verbatim,
which keeps the endpoint forward-compatible with new Anthropic
fields.

## Required fields

| Field        | Type    | Notes                                                                                                                                           |
| ------------ | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| `model`      | string  | A model ID from [`GET /v1/models`](/overview/model-catalog/).                                                                                   |
| `messages`   | array   | Roles must be `user` or `assistant`, must alternate, and the first message must be `user`. Use the top-level `system` field for system prompts. |
| `max_tokens` | integer | Positive integer.                                                                                                                               |

## Standard fields

| Field                | Type            | Forwarded? | Notes                                                                                                                  |
| -------------------- | --------------- | ---------- | ---------------------------------------------------------------------------------------------------------------------- |
| `stream`             | boolean         | —          | Consumed by the route handler to switch into SSE mode.                                                                 |
| `system`             | string \| array | Yes        | Optional system prompt. Use array of content blocks to attach `cache_control` (see [Prompt caching](#prompt-caching)). |
| `tools`              | array           | Yes        | Anthropic tool definitions (see [Tool use](/apis/messages/tool-use/)).                                                              |
| `tool_choice`        | object          | Yes        | Anthropic's standard tool-choice format.                                                                               |
| `temperature`        | number          | Yes        | Sampling control.                                                                                                      |
| `top_p`              | number          | Yes        | Nucleus sampling.                                                                                                      |
| `top_k`              | integer         | Yes        | Top-K sampling.                                                                                                        |
| `stop_sequences`     | array           | Yes        | Stop sequences.                                                                                                        |
| `context_management` | object          | Yes        | Anthropic's context-editing config (see [below](#context_management)).                                                 |

Anything not listed above passes through Kindo's schema verbatim
because the validator uses `passthrough()`. Refer to Anthropic's
[Messages spec](https://docs.anthropic.com/en/api/messages) for full
field semantics.

### `context_management`

Kindo forwards `context_management` for every model, regardless of
provider. Anthropic-family deployments honor it natively. For other
providers, Kindo applies it in-gateway — translating it to the
target API's equivalent mechanism where one exists, or polyfilling
the behavior where it doesn't. The response echoes
`context_management.applied_edits`, describing what was applied.

### Anthropic-specific headers

Kindo forwards these headers to the upstream provider when present:

- `anthropic-version`
- `anthropic-beta`
- `x-claude-code-session-id`

Anthropic SDKs and Claude Code set the required protocol headers
for you. Raw HTTP clients should include `anthropic-version`.

### Stripped-on-ingress fields

Kindo strips these fields from the outgoing upstream request:

- `metadata`
- `litellm_metadata`
- `proxy_server_request`

## Messages array

| Field     | Required | Notes                                                                                                                  |
| --------- | -------- | ---------------------------------------------------------------------------------------------------------------------- |
| `role`    | Yes      | `user` or `assistant`. Must alternate, must start with `user`.                                                         |
| `content` | Yes      | String or array of content blocks. Blocks include `text`, `tool_use`, `tool_result`, `image`, etc. Forwarded verbatim. |

System prompts go in the top-level `system` field, not in the
`messages` array.

### Compatibility normalization

Some OpenAI-compatible gateways and SDK shims emit Anthropic-bound
payloads with OpenAI-style role conventions. Kindo normalizes these
on ingress (on both `/v1/messages` and `/v1/messages/count_tokens`)
rather than rejecting them:

- A `system` or `developer` entry inside `messages[]` is hoisted into
  the top-level `system` field (string content and text-block-array
  content both work).
- A message with a missing `role` defaults to `user`.

The strict Anthropic shape above remains the recommended form —
normalization exists so unmodified OpenAI-gateway clients work, not
as an alternative contract.

## Prompt caching

Block-level `cache_control` works through Kindo. Add
`cache_control` to Anthropic content blocks and verify cache hits
from the response `usage` object.

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "max_tokens": 512,
  "system": [
    {
      "type": "text",
      "text": "You are a release-notes assistant. Always answer in bullet points.",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "Summarize the last three deploys for service api."
        }
      ]
    }
  ]
}
```

Look for these fields in `usage`:

- `cache_creation_input_tokens` — tokens written to cache on this
  request.
- `cache_read_input_tokens` — tokens read from cache on subsequent
  requests.

### Known limitation

Top-level `cache_control` is not currently forwarded by LiteLLM's
Anthropic TypedDict layer. Use **block-level** `cache_control`
instead.

If your client requires an Anthropic beta header for prompt caching,
use a header value supported by your target model. Internal
end-to-end verification confirmed
`anthropic-beta: prompt-caching-2024-07-31` works with Kindo's
proxy.

## `count_tokens`

`POST /v1/messages/count_tokens` counts tokens for a Messages
request without generating a completion.

```bash
curl https://api.kindo.ai/v1/messages/count_tokens \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-4-5-20250929",
    "system": "You are a concise assistant.",
    "messages": [
      { "role": "user", "content": "Summarize the principle of least privilege." }
    ]
  }'
```

| Field        | Required for `count_tokens` | Notes                         |
| ------------ | --------------------------- | ----------------------------- |
| `model`      | Yes                         |                               |
| `messages`   | Yes                         |                               |
| `max_tokens` | Optional                    |                               |
| `stream`     | Not supported               | Omit it or set it to `false`. |

Response:

```json
{ "input_tokens": 20 }
```

## Kindo extension fields

`/v1/messages` is stock Anthropic — Kindo does not accept a `kindo`
request block on this surface. Kindo's opt-in extensions (curated
system prompt, hosted tools, stateful conversations) are available
on `/v1/responses`; see the
[Chat Actions guide](/guides/chat-actions/).

## See also

- [Quickstart](/apis/messages/quickstart/) — minimal client setup.
- [Streaming](/apis/messages/streaming/) — SSE event types.
- [Tool use](/apis/messages/tool-use/) — `tool_use` / `tool_result` round trip.
- [Errors](/apis/messages/errors/) — Anthropic error envelope.

---

## Responses API request shape

Source: https://docs.kindo.ai/apis/responses/request-shape/

`POST /v1/responses` accepts the OpenAI Responses request body. The
goal is **bit-for-bit compatibility** with stock OpenAI clients —
anything you'd send to OpenAI's `/v1/responses` you can send to
Kindo's, with the same semantics.

This page documents what Kindo recognizes and how each field is
forwarded.

## Required fields

| Field   | Type                           | Notes                                                                                                                    |
| ------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| `model` | string                         | A model ID from [`GET /v1/models`](/overview/model-catalog/), or a stored Kindo agent as `agent/<agent-id>` (see below). |
| `input` | string \| array of input items | Plain string for single-turn, or array for multi-message / tool round trips.                                             |

### Agent models (`agent/<agent-id>`)

Passing `model: "agent/<agent-id>"` invokes one of your stored Kindo
agents instead of a raw model. The agent supplies the model, system
prompt, and tool set; your `input` is delivered to the run and your
`instructions` compose with (append after) the agent's own prompt.
Because the agent's configuration is pinned, request fields that
would override it — `tools`, a non-`"auto"` `tool_choice`,
`conversation`, `previous_response_id`, `background`, and sampling
parameters such as `temperature` — are rejected with
`400 unsupported_parameter` naming the field. Agent invocations
return immediately with `status: "in_progress"` and are polled or
streamed.

See [Invoke Kindo agents with the Responses API](/guides/invoke-agents-responses-api/)
for the full walkthrough.

### `input` array items

Each item is one of:

| `type`                 | Required fields                | Notes                                                                                                                                     |
| ---------------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `message`              | `role`, `content`              | `role` is `user`, `system`, `assistant`, or `developer`. `developer` is treated as a system-level instruction (matches OpenAI semantics). |
| `function_call`        | `call_id`, `name`, `arguments` | Accepted for conversation-history round-tripping. Re-sending one does not re-execute it.                                                  |
| `function_call_output` | `call_id`, `output`            | Returns a function tool's result; pair it with the originating `function_call.call_id`.                                                   |

### Message content parts

A `message` item's `content` is a plain string or an array of typed
parts:

| `type`        | Key fields                           | Notes                                                                                                                                                                                                                  |
| ------------- | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `input_text`  | `text`                               | Plain text.                                                                                                                                                                                                            |
| `input_image` | `image_url`                          | A `data:` URL or fetchable `https:` URL. Supported on both the stateless and stateful paths. The OpenAI `detail` hint is accepted; on the stateful path it is not propagated to the model.                             |
| `input_file`  | `file_data` / `file_id` / `file_url` | Stateless path only — forwarded to the upstream provider. On the stateful path (`store: true`, `conversation`, or `previous_response_id`), file parts are not carried to the model; send file content as text instead. |

**Data Loss Prevention.** If your organization has DLP policies
enabled, request text is scanned and redacted in-flight before it
reaches the model — this is transparent to the caller. File parts
interact with DLP explicitly: an `input_file` whose content cannot be
inspected (binary `file_data`, or a `file_id`/`file_url` reference) is
**rejected with `400`** rather than passed through unscanned, while
inline `file_data` with a text MIME type (`text/*`, JSON, CSV, source
code) is decoded, redacted, and forwarded. Without DLP enabled, file
parts pass through unmodified on the stateless path.

## Standard fields

Every field below is **forwarded verbatim** unless a row says
otherwise. Behavior matches OpenAI's published spec.

| Field                  | Type             | Forwarded?  | Notes                                                                                                                                                                                                                                                                      |
| ---------------------- | ---------------- | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `instructions`         | string           | Yes         | System-level instructions. Flow through unmodified by default.                                                                                                                                                                                                             |
| `tools`                | array            | Yes         | Mix `function`, `mcp`, and any `kindo_*` tools. Unknown types are forwarded verbatim. `mcp` tools require the stateful path (`store: true` or `conversation`); stateless requests including them are rejected with `400 unsupported_tool_type`.                            |
| `tool_choice`          | string \| object | Yes         | `"auto"`, `"none"`, `"required"`, `{type: "function", name: "..."}`, or `{type: "allowed_tools", ...}`.                                                                                                                                                                    |
| `stream`               | boolean          | —           | Consumed by the route handler to switch into SSE mode (see [Streaming](/apis/responses/streaming/)).                                                                                                                                                                                     |
| `store`                | boolean          | Yes         | When `true`, Kindo persists the response and returns a `conversation.id`. Default `false`.                                                                                                                                                                                 |
| `previous_response_id` | string           | —           | Continues the conversation that produced the referenced stored response (only responses created with `store: true` or `conversation` can be chained). Mutually exclusive with `conversation`. Unknown or inaccessible IDs → `404 previous_response_not_found`.             |
| `conversation`         | string           | Yes         | Existing Kindo-managed conversation ID to continue. Prior history is loaded server-side — send only the new turn in `input`. Mutually exclusive with `previous_response_id`.                                                                                               |
| `parallel_tool_calls`  | boolean          | Yes         | Forwarded to the upstream model.                                                                                                                                                                                                                                           |
| `prompt_cache_key`     | string           | Yes         | Forwarded; used by upstream providers that support prompt caching.                                                                                                                                                                                                         |
| `reasoning`            | object           | Yes         | OpenAI reasoning controls (e.g. `effort`).                                                                                                                                                                                                                                 |
| `text`                 | object           | Yes         | OpenAI text-output controls (e.g. `format`, `verbosity`).                                                                                                                                                                                                                  |
| `include`              | array of strings | Yes         | Request additional output items (e.g. encrypted reasoning content).                                                                                                                                                                                                        |
| `truncation`           | string           | Yes         | OpenAI truncation policy.                                                                                                                                                                                                                                                  |
| `background`           | boolean          | Yes\*       | OpenAI background-execution flag. \*On the stateful path (`store: true` or `conversation` set), `background: true` is rejected with `400 unsupported_parameter` — background execution is not yet supported on Kindo-managed conversations. Omit it or use `stream: true`. |
| `service_tier`         | string           | Yes         | OpenAI service-tier hint.                                                                                                                                                                                                                                                  |
| `max_output_tokens`    | integer          | Yes         | Standard sampling control.                                                                                                                                                                                                                                                 |
| `temperature`          | number           | Yes         | Standard sampling control.                                                                                                                                                                                                                                                 |
| `top_p`                | number           | Yes         | Standard sampling control.                                                                                                                                                                                                                                                 |
| `n`                    | integer          | Yes         | Standard sampling control.                                                                                                                                                                                                                                                 |
| `stop`                 | string \| array  | Yes         | Standard sampling control.                                                                                                                                                                                                                                                 |
| `metadata`             | object           | Stored only | Echoed back in the response object. Not forwarded to the model layer.                                                                                                                                                                                                      |

Anything not listed above passes through Kindo's schema verbatim, so
new OpenAI-spec additions land at Kindo automatically when supported
by the upstream model.

### Stripped-on-ingress fields

Kindo strips these fields from the outgoing upstream request to prevent governance-metadata spoofing:

- `metadata`
- `litellm_metadata`
- `proxy_server_request`

(`metadata` is stored and echoed back in the response; it is not forwarded to the model layer — see the row above.)

### Response store pruning

When `store: true`, Kindo persists the response object so it can be
fetched later via `GET /v1/responses/{id}`. Stored responses are not
kept indefinitely — once a response is pruned (whether by retention
policy expiry or explicit deletion), subsequent fetches by ID return
`404 not_found` with no `error.code` set. This is the same status the
endpoint returns for IDs that never existed; the two cases are not
distinguished in the response envelope.

If you need durable access to a response body, capture it from the
original `POST /v1/responses` call rather than relying on the stored
copy.

See the [`404` row in the errors table](/apis/responses/errors/#status--type--code-reference) for the matching error envelope.

## Read endpoints

Two `GET` endpoints accompany `POST /v1/responses` for stored
responses:

### `GET /v1/responses/{response_id}`

Fetches the response object by ID — the polling mechanism for
agent-run responses (`resp_run_*`) and the way to re-read any stored
response. Add `?stream=true` (optionally with `starting_after`) to
reconnect to the response's SSE stream instead — see
[Streaming → resuming a dropped stream](/apis/responses/streaming/#resuming-a-dropped-stream).

### `GET /v1/responses/{response_id}/input_items`

Returns the user input that initiated a stored response, as an
OpenAI-style list envelope:

```json
{
  "object": "list",
  "data": [
    {
      "id": "msg_abc123",
      "type": "message",
      "role": "user",
      "content": [{ "type": "input_text", "text": "Summarize CVE-2024-3094." }],
      "status": "completed"
    }
  ],
  "has_more": false,
  "first_id": "msg_abc123",
  "last_id": "msg_abc123"
}
```

The list contains the response's originating user message (an empty
`data` array when the response had no user input message). `has_more`
is always `false` — pagination parameters are not supported on this
endpoint. For the full conversation history around a stored response,
use the [Conversations API](/apis/conversations/quickstart/) with the
response's `conversation.id`.

## Kindo extension fields

These are **opt-in** and documented in detail at
[Chat Actions extensions](/apis/responses/kindo-extensions/):

| Field                          | Type                         | Notes                                                                                                                                                                                                                                                                                                                                                                                                                                     |
| ------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `kindo.system_prompt`          | `"agent_default"` \| `"off"` | When `"agent_default"`, Kindo prepends its curated operational prompt to your `instructions`. On stateful requests (`store: true`, `conversation`, or `previous_response_id`), Kindo includes service-managed context with the composed prompt and supplies the current date and timezone with the triggering input. Default `"off"` does not add either form of service-managed context; client instructions and input remain unchanged. |
| `tools[].type: "kindo_tools"`  | sugar entry                  | Expands at request time to the current set of individual `kindo_<name>` entries.                                                                                                                                                                                                                                                                                                                                                          |
| `tools[].type: "kindo_<name>"` | individual hosted-tool entry | E.g. `kindo_shell`, `kindo_web_search`. See [Chat Actions extensions](/apis/responses/kindo-extensions/) for the full list.                                                                                                                                                                                                                                                                                                                             |

On compacted stateful turns, a service-managed compaction hint may be
appended; it follows composed instructions and other service-managed
prompt guidance. With `off`, caller instructions are preserved; the
separate compaction hint may still be added.

The `kindo` block and `kindo_*` tool types are the only Kindo-specific
additions to the request body. Everything else on this page is stock
OpenAI Responses.

## Worked example

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "input": [
    {
      "type": "message",
      "role": "developer",
      "content": "You are a concise security assistant."
    },
    { "type": "message", "role": "user", "content": "Summarize CVE-2024-3094." }
  ],
  "tools": [
    {
      "type": "function",
      "name": "lookup_cve",
      "description": "Fetch CVE metadata.",
      "parameters": {
        "type": "object",
        "properties": { "id": { "type": "string" } },
        "required": ["id"]
      }
    }
  ],
  "tool_choice": "auto",
  "store": true,
  "max_output_tokens": 512,
  "temperature": 0.2
}
```

This request is stock OpenAI Responses. Kindo accepts it identically
to OpenAI's `/v1/responses`, plus persists the response and returns a
`conversation.id` because `store: true` is set.

## See also

- [Quickstart](/apis/responses/quickstart/) — minimal client setup.
- [Streaming](/apis/responses/streaming/) — SSE event types.
- [Tool use](/apis/responses/tool-use/) — function-calling round trip.
- [Errors](/apis/responses/errors/) — error envelope.
- [Chat Actions extensions](/apis/responses/kindo-extensions/) — `kindo` block,
  `kindo_*` tools, statefulness opt-ins.

---

## Working with Large Context

Source: https://docs.kindo.ai/best-practices/working-with-large-context/

Large language models are powerful, but their biggest practical constraint is the **context window**: the maximum amount of text and tool state they can process in a single request. In Kindo, context includes your instructions, conversation history, and — for agents — tool calls and tool outputs.

As that grows, you can hit hard limits, degrade output quality, and increase inference cost because more tokens are processed on every turn.

This guide covers practical techniques you can use in Kindo to keep large-context agents reliable.

## How Kindo Helps

Kindo mitigates large tool outputs by writing them into the **sandbox** and passing the model a reference to the file rather than injecting the full payload into the prompt. That enables an important pattern: instead of asking the model to read massive blobs, use the sandbox to search, filter, and transform data first — then feed the model only the high-signal subset.

## Technique 1: Reduce Data Volume at the Source

The best way to prevent context blowups is to avoid retrieving unnecessary data in the first place. Most systems you integrate with provide filters that narrow results before they ever reach the model.

Common query levers include:

- Time bounds: last 15 minutes, incident window, since alert fired
- Severity: errors only, warnings + errors, critical only
- Scope: service, environment, host, region, tenant
- Identifiers: incident ID, trace ID, correlation ID
- Pattern filters: keywords or error codes
- Pagination and limits: fetch small batches first, then expand only if needed

The habit to build is: **start narrow, validate the signal, then widen intentionally**.

### Example Prompts

```text
Pull logs for only the incident window (10:12–10:47 UTC) and only error-level entries for service=api-gateway in prod. If that returns nothing, expand to warnings+errors.

Query the alerting system for alert_id=12345 and fetch only the related events and the top 50 associated log lines, not the entire day.

Fetch only authentication-related events for tenant=acme during the last 2 hours and include only timestamp, user, source_ip, action, and result.
```

## Technique 2: Use the Sandbox to Sift Large Payloads

Even with upstream filtering, outputs can still be too large for a model to read efficiently. When the data is in the sandbox, let traditional tools do the heavy lifting.

Useful tools include:

- `grep` / `rg` for searching by signature, ID, or keyword
- `find` for locating generated files
- `sed` / `awk` for extracting ranges or fields
- Bash scripts for repeatable extraction pipelines
- Python scripts for grouping, aggregation, parsing JSON/CSV, and top-N summaries

Common patterns:

- Search for an error signature and extract a small context window around each match
- Group events by correlation ID or error code and output counts plus representative examples
- Parse structured logs into a compact report with top errors, affected hosts, and a short timeline

### Example Prompts

```text
The tool output was written to a file in the sandbox. Do not read the full file into context.
Use grep/rg to find all lines containing "Exception" or "ERROR", group by the most common error prefix, and output:
- top 5 error clusters with counts
- first/last timestamp per cluster
- 2 representative excerpts per cluster

Find the sandbox file containing the raw response. If it is JSON, write a short Python script to:
- parse it
- group by correlation_id
- output the 10 largest groups with one-line summaries
Then summarize only the script output.
```

## Technique 3: Use MapReduce-Style Processing

When you truly need to process large bodies of content — such as multi-hour logs, many tickets, or large document sets — a single-pass prompt is often brittle. A MapReduce-style approach is more reliable.

### Map Phase

Split the input by a natural boundary such as:

- time slice
- file
- service
- ticket

For each chunk, extract only the minimum useful signal:

- key events and timestamps
- recurring patterns or clusters
- important entities (services, users, IDs)
- a few representative examples

Write those chunk summaries back to the sandbox as small JSON or Markdown artifacts.

### Reduce Phase

Then have a model read only the chunk summaries and synthesize:

- timeline
- root cause hypothesis
- remediation steps
- supporting evidence

This pattern works especially well when combined with **model tiering**:

- use a smaller/cheaper model for extraction
- use a stronger reasoning model for the final synthesis

### Example Two-Step Approach

**Step 1 — extraction / chunk summaries**

```text
We have 12 log chunks in /sandbox/log_chunks/.

For each file, produce a compact JSON summary with:
- file
- time_range
- top_errors (signature, count, first_seen, last_seen, short examples)
- notable_events
- correlation_ids

Write one JSON file per chunk to /sandbox/log_summaries/.
Do not include raw logs in the output.
```

**Step 2 — final synthesis**

```text
Read only the JSON summaries in /sandbox/log_summaries/.

Produce:
1. A concise incident timeline
2. The most likely root cause
3. The top 3 remediation steps
4. The key evidence supporting each conclusion

If more raw data is required, specify exactly what to grep for and why instead of asking to read everything.
```

## Recommended Working Style

When working with large context in Kindo:

1. Narrow the query upstream first
2. Use the sandbox for search, filtering, and summarization
3. Break large tasks into chunked phases
4. Reserve the strongest model for synthesis, not raw parsing
5. Avoid feeding large raw payloads into the model unless you have already reduced them substantially

## Automatic Compaction

Long conversations are compacted automatically. When a conversation approaches the model's context window, Kindo summarizes earlier messages while keeping recent context, so the session can continue without losing the thread — there is no need to start over or manage the context yourself. This happens in the background as you work, and the chat interface marks the conversation where it occurs. The techniques above remain the most effective way to control what enters the context in the first place.

## Future Platform Improvements

Kindo can make context management more automatic. Areas that could improve this experience include:

- more dynamic prompt loading so only relevant instructions are included per task
- deeper prompt-prefix caching optimizations
- better durable memory patterns for agents

Regardless of future improvements, the most reliable pattern remains: **use traditional compute to reduce the data, then use the model to interpret the reduced result**.

---

## Connect to Microsoft MCP integrations

Source: https://docs.kindo.ai/connecting-integrations/microsoft-mcp/

Most Microsoft MCP integrations use the same connection pattern:

1. Create an app registration in Microsoft Entra ID.
2. Create a client secret.
3. Create the integration in Nango and add the client ID and client secret.
4. Copy the OAuth callback URL from Nango and add it to the app registration as a Web redirect URI under **Authentication**.
5. Add the Microsoft API permissions required by the integration.
6. Complete the Microsoft authorization flow.

This page covers the common setup. Each Microsoft integration still has its own permission list. Use the permission list provided by Kindo for the integration you are connecting.

:::caution[Use the exact permissions for your integration]
Do not grant broad Microsoft Graph permissions "just in case." Add only the permissions required for the specific integration and tools you plan to use.
:::

## Applies to

Use this guide for Microsoft integrations that authenticate through Microsoft Entra ID, including:

- Microsoft Azure
- Microsoft Defender
- Microsoft Defender for Cloud
- Microsoft eDiscovery
- Microsoft Entra ID
- Microsoft Entra ID Governance
- Microsoft Excel Online
- Microsoft Fabric
- Microsoft Graph Security (Microsoft Defender XDR)
- Microsoft Intune
- Microsoft Outlook
- Microsoft Purview Compliance
- Microsoft Purview Data Governance
- Microsoft Teams
- SharePoint Online

Some integrations need extra tenant, endpoint, subscription, or target-user values. If Kindo gives you additional fields for a specific integration, enter them in the Kindo integration form after you complete the common Entra setup.

## Prerequisites

- A Microsoft Entra ID tenant.
- Permission to create or update app registrations in that tenant.
- Permission to grant admin consent if the requested Microsoft API permissions require it.
- Access to the Nango dashboard for your Kindo deployment.
- The permission list for the Microsoft integration you are connecting.

## Step 1: Create the Entra app registration

## Step 2: Copy the client ID

## Step 3: Create a client secret

:::caution[Copy the secret value, not the secret ID]
Microsoft only shows the secret **Value** once. Kindo needs the secret value. The secret ID will not work.
:::

## Step 4: Create the integration in Nango

## Step 5: Add the Nango callback URL to the app registration

## Step 6: Add Microsoft API permissions

### How delegated permissions work

Delegated permissions act as the signed-in user. The integration's effective access is the **intersection** of two grants:

- the permissions granted to the application, and
- the permissions the signed-in user already has in the tenant.

The integration can never reach data the signed-in user cannot access themselves, and the user's access through the integration is limited to what the registered application's permissions allow. For example, if the app holds `Sites.ReadWrite.All` but the signed-in user only has read access to a SharePoint site, the integration cannot write to that site.

### Integration-specific permissions

#### Microsoft Azure

This integration authenticates against **Azure Resource Manager**, not Microsoft
Graph. An app registration set up for a Graph integration on this page will not
work here, and vice versa.

The app registration is still created in Microsoft Entra ID: Azure identity
lives in Entra, so an Azure Resource Manager token is an Entra token.

Add the following instead of the Microsoft Graph permissions:

| API | Permission | Type | Admin consent required |
| --- | --- | --- | --- |
| Azure Resource Manager | `user_impersonation` | Delegated | No |

Find **Azure Resource Manager** under the **APIs my organization uses** tab
when adding a permission (App ID `797f4846-ba00-4fd7-ba43-dac1f8f63013`).

When linking the connection, Kindo also asks for:

| Field | Description |
| --- | --- |
| **Tenant ID** | App registration > Overview > Directory (tenant) ID |
| **Subscription ID** | Optional. The default subscription for tools that need one. Management-group and tenant-scoped tools work without it. |

The `user_impersonation` permission grants no access to any Azure resource. It
only lets Kindo sign you in and request an Azure Resource Manager token on your
behalf. What that token can read comes entirely from Azure RBAC, so also assign
a role to your account (Azure Portal > Subscriptions > your subscription >
**Access control (IAM)** > Add role assignment):

| Role | Grants |
| --- | --- |
| **Reader** | All read tools: subscriptions, resource groups, resources, policy and compliance, RBAC, and management groups |

Assign **Reader** at a management group instead to cover every subscription
beneath it in one assignment.

##### Microsoft Azure — Application mode

Microsoft Azure can also connect in **application mode**, where the integration
authenticates as the app itself (client credentials) instead of as a signed-in
user. Use the **Microsoft Azure (Application)** integration in Kindo. Set it up
as its own integration, with its own app registration, client ID, and client
secret — Steps 1 to 4 on this page apply unchanged.

Two things differ from the delegated setup above.

**Skip Step 6.** Application mode needs no API permissions at all. Azure
Resource Manager exposes no application permissions, so there is nothing to add
and nothing to consent. Adding Microsoft Graph application permissions grants a
service principal no Azure access.

**Assign the RBAC role to the app, not to yourself.** With no signed-in user,
the service principal is the only identity involved, so it needs the role
directly (Azure Portal > Subscriptions > your subscription > **Access control
(IAM)** > Add role assignment > **Reader** > Members > **User, group, or service
principal**, then search for the app registration by name). Assign at a
management group to cover every subscription beneath it.

##### Microsoft Azure — US Government

Select the **Microsoft Azure (Government)** integration in Kindo rather than
**Microsoft Azure**, and create its app registration in the Azure Government
portal at [portal.azure.us](https://portal.azure.us). A commercial app
registration cannot be used.

Add the same permission, connection fields, and RBAC role as above.

Azure has no separate GCC and GCC High tiers — every Azure Government
subscription uses this integration.

#### Microsoft Defender

This integration uses permissions from three APIs: **Microsoft Graph**, **Microsoft Threat Protection**, and **WindowsDefenderATP**. All of them are **Delegated** permissions. Find Microsoft Threat Protection and WindowsDefenderATP under the **APIs my organization uses** tab when adding a permission.

Add the following **Microsoft Graph** permissions:

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `User.Read` | Sign in and read user profile | No |

Add the following **Microsoft Threat Protection** permissions:

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `Incident.Read` | Read incidents | Yes |
| `Incident.ReadWrite` | Read and write incidents | Yes |

Add the following **WindowsDefenderATP** permissions:

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `AdvancedQuery.Read` | Run advanced queries | Yes |
| `Alert.Read` | Read alerts | Yes |
| `Alert.ReadWrite` | Read and write alerts | Yes |
| `Machine.Isolate` | Isolate machine | Yes |
| `Machine.Read` | Read machine information | Yes |
| `Machine.Scan` | Scan machine | Yes |
| `Ti.ReadWrite` | Read and write IOCs | Yes |

:::caution[Requires an active Defender for Endpoint subscription]
This integration also requires an active **Microsoft Defender for Endpoint**
subscription on the tenant, separate from the permissions above.
:::

##### Microsoft Defender — GCC High

Select the **Microsoft Defender for Endpoint (GCC High)** integration in Kindo
rather than **Microsoft Defender**, and create its app registration in the Azure
Government portal at [portal.azure.us](https://portal.azure.us). A commercial app
registration cannot be used.

Add the same permissions listed above.

This integration supports GCC High and DoD tenants. GCC tenants are not
supported.

#### Microsoft Defender for Cloud

This is a separate integration and product from Microsoft Defender above — it
authenticates against **Azure Resource Manager**, not Microsoft Graph, so its
setup differs from the other integrations on this page. An app registration
set up for Microsoft Defender will not work here, and vice versa.

Add the following permission instead of Microsoft Graph:

| API | Permission | Type | Admin consent required |
| --- | --- | --- | --- |
| Azure Resource Manager | `user_impersonation` | Delegated | No |

Find **Azure Resource Manager** under the **APIs my organization uses** tab
when adding a permission (App ID `797f4846-ba00-4fd7-ba43-dac1f8f63013`).

When linking the connection, Kindo also asks for:

| Field | Description |
| --- | --- |
| **Tenant ID** | App registration > Overview > Directory (tenant) ID |
| **Subscription ID** | The Azure subscription to monitor with Defender for Cloud |

In addition to the Entra app permission, assign an Azure RBAC role to your
account on that subscription (Azure Portal > Subscriptions > your
subscription > **Access control (IAM)** > Add role assignment):

| Role | Grants |
| --- | --- |
| **Security Reader** | All read tools (alerts, recommendations, secure score, compliance overview, security coverage) |
| **Security Admin** | Everything Security Reader does, plus dismissing/updating alerts |

`list_alerts` returns empty until at least one paid Defender plan (e.g.
Defender for Servers) is enabled on the subscription — the free tier still
covers secure score, recommendations, and compliance overview.

##### Microsoft Defender for Cloud — US Government

Select the **Microsoft Defender for Cloud (Government)** integration in Kindo
rather than **Microsoft Defender for Cloud**, and create its app registration in
the Azure Government portal at [portal.azure.us](https://portal.azure.us). A
commercial app registration cannot be used.

Add the same permission, connection fields, and RBAC role as above.

Some tools return fewer results than in the commercial cloud:

| Tool | In Azure Government |
| --- | --- |
| `list_recommendation_findings` | Machine vulnerability findings aren't included. |
| `list_security_coverage` | Defender for AI Services, App Service, and Azure Cosmos DB aren't listed. |
| `get_compliance_overview` | The available compliance standards differ. |

#### Microsoft eDiscovery

Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `eDiscovery.Read.All` | Read all eDiscovery objects | Yes |
| `eDiscovery.ReadWrite.All` | Read and write all eDiscovery objects | Yes |
| `offline_access` | Maintain access to data you have given it access to | No |
| `User.Read` | Sign in and read user profile | No |

##### Microsoft eDiscovery — Application mode

Microsoft eDiscovery can also connect in **application mode**, where the integration
authenticates as the app itself (client credentials) instead of as a signed-in user.
This is a separate connection from the standard delegated eDiscovery integration
above — set it up as its own Kindo integration if you need automation that runs
without a signed-in user.

:::caution[Two setup steps, not one]
Granting the Microsoft Graph application permissions below is not enough by
itself. eDiscovery access is also gated by a separate Microsoft Purview RBAC
registration — see Step B below.
:::

###### Step A: Grant the Graph application permissions

Add the following **Microsoft Graph** permissions as **Application** permissions
(not Delegated) on the app registration:

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `eDiscovery.Read.All` | Read all eDiscovery objects | Yes |
| `eDiscovery.ReadWrite.All` | Read and write all eDiscovery objects | Yes |

###### Step B: Register the app in Microsoft Purview's RBAC layer

This step happens in Security & Compliance PowerShell, not in Entra ID or the
Purview portal UI — service principals cannot be added to eDiscovery role groups
directly from the portal.

**Prerequisites for Step B:**

- The tenant must have **Microsoft Purview eDiscovery (Premium)** licensed. A
  missing license produces the same `401` symptom even when both steps above are
  done correctly.
- An account with the **Role Management** role in Microsoft Purview, to run the
  `RoleGroupMember`/`eDiscoveryCaseAdmin` cmdlets above.

#### Microsoft Entra ID

Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `AppRoleAssignment.ReadWrite.All` | Manage app permission grants and app role assignments | Yes |
| `AuditLog.Read.All` | Read audit log data | Yes |
| `Directory.Read.All` | Read directory data | Yes |
| `DirectoryRecommendations.Read.All` | Read Azure AD recommendations | Yes |
| `Group.Read.All` | Read all groups | Yes |
| `GroupMember.Read.All` | Read group memberships | Yes |
| `offline_access` | Maintain access to data you have given it access to | No |
| `Policy.Read.All` | Read your organization's policies | Yes |
| `Policy.Read.AuthenticationMethod` | Read authentication method policies | Yes |
| `Policy.Read.ConditionalAccess` | Read your organization's conditional access policies | No |
| `Reports.Read.All` | Read all usage reports | Yes |
| `RoleManagement.Read.Directory` | Read directory RBAC settings | Yes |
| `User.EnableDisableAccount.All` | Enable and disable user accounts | Yes |
| `User.Read` | Sign in and read user profile | No |
| `User.Read.All` | Read all users' full profiles | Yes |
| `User.ReadBasic.All` | Read all users' basic profiles | No |

##### Microsoft Entra ID — conditional access

:::caution[The What If tool needs Entra ID P1]
Evaluating a hypothetical sign-in requires a Microsoft Entra ID P1 or P2 licence.
Without one it returns *Your tenant is not licensed for this feature.* Office 365 E5
does not include Entra ID P1.
:::

Reading conditional access policies and counting their impact from sign-in logs work
without a premium licence. A tenant with no conditional access policies is usually
running on Security Defaults, which the impact tools report by that name.

##### Microsoft Entra ID — Application mode

Microsoft Entra ID can also connect in **application mode**, where the integration
authenticates as the app itself (client credentials) instead of as a signed-in user.
This is a separate connection from the delegated integration above — set it up as its
own Kindo integration if you need automation that runs without a signed-in user.

Add the following **Microsoft Graph** permissions as **Application** permissions
(not Delegated) on the app registration. The set differs slightly from the
delegated list: application mode reads app role assignments with
`Directory.Read.All` and resolves users with `User.Read.All`.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `AuditLog.Read.All` | Read all audit log data | Yes |
| `Directory.Read.All` | Read directory data | Yes |
| `DirectoryRecommendations.Read.All` | Read all Azure AD recommendations | Yes |
| `Group.Read.All` | Read all groups | Yes |
| `GroupMember.Read.All` | Read all group memberships | Yes |
| `Policy.Read.All` | Read your organization's policies | Yes |
| `Policy.Read.AuthenticationMethod` | Read authentication method policies | Yes |
| `Policy.Read.ConditionalAccess` | Read your organization's conditional access policies | Yes |
| `Reports.Read.All` | Read all usage reports | Yes |
| `RoleManagement.Read.Directory` | Read all directory RBAC settings | Yes |
| `User.EnableDisableAccount.All` | Enable and disable user accounts | Yes |
| `User.Read.All` | Read all users' full profiles | Yes |

Two reports are delegated-only: Microsoft does not support application
permissions for the authentication-method registration summary or the
application sign-in summary, so those two tools fail on an application
connection. Everything else works in either mode.

#### Microsoft Entra ID Governance

Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `AccessReview.Read.All` | Read all access reviews that user can access | Yes |
| `AccessReview.ReadWrite.All` | Manage all access reviews that user can access | Yes |
| `EntitlementManagement.Read.All` | Read all entitlement management resources | Yes |
| `EntitlementManagement.ReadWrite.All` | Read and write entitlement management resources | Yes |
| `LifecycleWorkflows-Reports.Read.All` | Read all Lifecycle workflows reports | Yes |
| `LifecycleWorkflows-Workflow.Activate` | Run workflows on demand in Lifecycle workflows | Yes |
| `LifecycleWorkflows-Workflow.ReadBasic.All` | List all workflows in Lifecycle workflows | Yes |
| `offline_access` | Maintain access to data you have given it access to | No |
| `PrivilegedAssignmentSchedule.Read.AzureADGroup` | Read assignment schedules for access to Azure AD groups | Yes |
| `PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup` | Read, create, and delete assignment schedules for access to Azure AD groups | Yes |
| `PrivilegedEligibilitySchedule.Read.AzureADGroup` | Read eligibility schedules for access to Azure AD groups | Yes |
| `PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup` | Read, create, and delete eligibility schedules for access to Azure AD groups | Yes |
| `RoleAssignmentSchedule.Read.Directory` | Read all active role assignments for your company's directory | Yes |
| `RoleAssignmentSchedule.ReadWrite.Directory` | Read, update, and delete all active role assignments for your company's directory | Yes |
| `RoleEligibilitySchedule.Read.Directory` | Read all eligible role assignments for your company's directory | Yes |
| `RoleEligibilitySchedule.ReadWrite.Directory` | Read, update, and delete all eligible role assignments for your company's directory | Yes |
| `RoleManagement.Read.Directory` | Read directory RBAC settings | Yes |
| `User.Read` | Sign in and read user profile | No |

:::caution[PIM and Lifecycle Workflows need extra tenant licensing]
- **Privileged Identity Management (PIM)** (role/group assignment and
  eligibility schedules) requires **Microsoft Entra ID P2** (or Microsoft 365
  E5).
- **Lifecycle Workflows** requires the separate **Microsoft Entra ID
  Governance** license.
:::

#### Microsoft Excel Online

Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `Files.Read` | Read user files | No |
| `Files.ReadWrite` | Have full access to user files | No |
| `offline_access` | Maintain access to data you have given it access to | No |
| `User.Read` | Sign in and read user profile | No |

#### Microsoft Fabric

This integration authenticates as the app itself (a service principal using client credentials) instead of as a signed-in user, so its setup differs from the other integrations on this page:

- **No additional API permissions are required.** The default `User.Read` permission that Entra adds to every new app registration is enough, and it does not need admin consent.
- **No redirect URI or user sign-in flow is needed.** Skip Step 5, the Callback URL substep of Step 4, and the sign-in portion of Step 7. Use the Fabric connection form below instead of the Step 4 credentials table.
- **Access is controlled inside Microsoft Fabric, not in Entra.** Queries run with the service principal's permissions, so grant it only the read access you intend to expose.

Configure the service principal in Microsoft Fabric:

When linking the Microsoft Fabric account, the connection form asks for the following values:

| Field | Description |
| --- | --- |
| **Tenant ID** | App registration > Overview > Directory (tenant) ID |
| **SQL Endpoint Host** | Full `host,port` of the Fabric Lakehouse SQL endpoint, for example `foo.datawarehouse.fabric.microsoft.com,1433` |
| **Lakehouse Database** | Database/lakehouse name |
| **Client ID** | App registration > Overview > Application (client) ID |
| **Client Secret** | App registration > Certificates & secrets > Client secrets > Value |

#### Microsoft Graph Security (Microsoft Defender XDR)

"Microsoft Graph Security" is Kindo's internal name for this integration
(matching the Graph `/security/...` namespace it calls); Microsoft's product
name for the same surface is **Defender XDR** (formerly Microsoft 365
Defender) — the unified security portal correlating signals across Defender
for Endpoint, Defender for Office 365, Defender for Identity, Defender for
Cloud Apps, and Entra ID Protection. It's a different product from both
**Microsoft Defender** (Defender for Endpoint specifically, a separate
integration on this page) and **Microsoft Defender for Cloud** (Azure's cloud
security posture management, unrelated to the Defender XDR family).

Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `IdentityRiskyUser.Read.All` | Read identity risky user information | Yes |
| `IdentityRiskyUser.ReadWrite.All` | Read and write risky user information | Yes |
| `offline_access` | Maintain access to data you have given it access to | No |
| `SecurityAlert.Read.All` | Read all security alerts | Yes |
| `SecurityAlert.ReadWrite.All` | Read and write to all security alerts | Yes |
| `SecurityEvents.Read.All` | Read your organization's security events | Yes |
| `SecurityIncident.Read.All` | Read incidents | Yes |
| `SecurityIncident.ReadWrite.All` | Read and write to incidents | Yes |
| `ThreatHunting.Read.All` | Run hunting queries | Yes |
| `User.Read` | Sign in and read user profile | No |

:::caution[Some tools need extra licensing, not just permissions]
- **Risky users** requires **Microsoft Entra ID P2** (or Microsoft 365 E5) to
  be licensed on the tenant.
- **Advanced hunting** device-scoped tables like `DeviceInfo` require
  **Microsoft Defender for Endpoint** to be licensed.
:::

##### Microsoft Graph Security — Application mode

Microsoft Graph Security can also connect in **application mode**, where the
integration authenticates as the app itself (client credentials) instead of
as a signed-in user. This is a separate connection from the delegated
integration above — set it up as its own Kindo integration if you need
automation that runs without a signed-in user.

Add the same permissions listed above, but as **Application** permissions
(not Delegated) on the app registration. Unlike eDiscovery's application
mode, this one doesn't need any extra RBAC registration step — the Graph
application permissions alone are sufficient.

#### Microsoft Intune

Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `DeviceManagementApps.Read.All` | Read Microsoft Intune apps | Yes |
| `DeviceManagementConfiguration.Read.All` | Read Microsoft Intune Device Configuration and Policies | Yes |
| `DeviceManagementManagedDevices.PrivilegedOperations.All` | Perform user-impacting remote actions on Microsoft Intune devices | Yes |
| `DeviceManagementManagedDevices.Read.All` | Read Microsoft Intune devices | Yes |
| `offline_access` | Maintain access to data you have given it access to | No |
| `User.Read` | Sign in and read user profile | No |

:::caution[Requires an active Intune license on the tenant]
This integration also requires **Microsoft Intune** to be licensed on the
tenant (bundled with Microsoft 365 E3/E5, Microsoft 365 Business Premium,
Enterprise Mobility + Security E3/E5, or standalone Intune Plan 1), separate
from the permissions above.
:::

##### Microsoft Intune — Application mode

Microsoft Intune can also connect in **application mode**, where the
integration authenticates as the app itself (client credentials) instead of
as a signed-in user. This is a separate connection from the delegated
integration above — set it up as its own Kindo integration if you need
automation that runs without a signed-in user.

Add the same permissions listed above, but as **Application** permissions
(not Delegated) on the app registration. The tenant licensing requirement
above applies to this mode too.

#### Microsoft Outlook

Covers mail, calendar, and contacts in one integration. Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions. Mail is read and sent as the signed-in user.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `Calendars.Read` | Read user calendars | No |
| `Calendars.Read.Shared` | Read user and shared calendars | No |
| `Calendars.ReadBasic` | Read basic details of user calendars | No |
| `Calendars.ReadWrite` | Have full access to user calendars | No |
| `Contacts.Read` | Read user contacts | No |
| `Mail.Read` | Read user mail | No |
| `Mail.ReadBasic` | Read user basic mail | No |
| `Mail.Send` | Send mail as a user | No |
| `offline_access` | Maintain access to data you have given it access to | No |
| `People.Read` | Read users' relevant people lists | No |
| `User.Read` | Sign in and read user profile | No |

#### Microsoft Outlook Calendar

Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `Calendars.Read` | Read user calendars | No |
| `Calendars.Read.Shared` | Read user and shared calendars | No |
| `Calendars.ReadBasic` | Read basic details of user calendars | No |
| `Calendars.ReadWrite` | Have full access to user calendars | No |
| `offline_access` | Maintain access to data you have given it access to | No |
| `User.Read` | Sign in and read user profile | No |

`find_meeting_times` needs `Calendars.Read.Shared` — it reads attendee
availability, which the unshared calendar permissions don't cover.

#### Microsoft Purview Compliance

Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `AuditLogsQuery.Read.All` | Read audit logs data from all services | Yes |
| `Content.Process.User` | Process content for data security, governance and compliance | Yes |
| `Files.ReadWrite.All` | Have full access to all files user can access | No |
| `InformationProtectionPolicy.Read` | Read user sensitivity labels and label policies. | No |
| `offline_access` | Maintain access to data you have given it access to | No |
| `ProtectionScopes.Compute.User` | Compute Purview policies for an individual user | Yes |
| `SecurityAlert.Read.All` | Read all security alerts | Yes |
| `SecurityAlert.ReadWrite.All` | Read and write to all security alerts | Yes |
| `SecurityIncident.Read.All` | Read incidents | Yes |
| `SecurityIncident.ReadWrite.All` | Read and write to incidents | Yes |
| `ThreatHunting.Read.All` | Run hunting queries | Yes |
| `User.Read` | Sign in and read user profile | No |

##### Microsoft Purview Compliance — Application mode

Microsoft Purview Compliance can also connect in **application mode**, where
the integration authenticates as the app itself (client credentials) instead
of as a signed-in user. This is a separate connection from the delegated
integration above — set it up as its own Kindo integration if you need
automation that runs without a signed-in user. Tested and confirmed working.

Add the following **Microsoft Graph** permissions as **Application** permissions
(not Delegated) on the app registration. Two differ from the delegated list:
sensitivity labels come from the tenant catalog with
`InformationProtectionPolicy.Read.All`, and protection scopes are computed
tenant-wide with `ProtectionScopes.Compute.All`.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `AuditLogsQuery.Read.All` | Read audit logs data from all services | Yes |
| `Content.Process.User` | Process content for data security, governance and compliance | Yes |
| `Files.ReadWrite.All` | Read and write files in all site collections | Yes |
| `InformationProtectionPolicy.Read.All` | Read all published labels and label policies for an organization. | Yes |
| `ProtectionScopes.Compute.All` | Compute Purview policies at tenant scope | Yes |
| `SecurityAlert.Read.All` | Read all security alerts | Yes |
| `SecurityAlert.ReadWrite.All` | Read and write to all security alerts | Yes |
| `SecurityIncident.Read.All` | Read all security incidents | Yes |
| `SecurityIncident.ReadWrite.All` | Read and write to all security incidents | Yes |
| `ThreatHunting.Read.All` | Run hunting queries | Yes |

For the `Content.Process.User` / `ProtectionScopes.Compute.User` tools
specifically: DLP policies must be created with the `New-DlpComplianceRule`
PowerShell cmdlet to apply to Entra-registered (app-only) callers — policies
created in the Purview portal UI don't apply to them.

#### Microsoft Purview Data Governance

This integration uses permissions from two APIs: **Microsoft Graph** and **Microsoft Purview**. All of them are **Delegated** permissions. Find Microsoft Purview under the **APIs my organization uses** tab when adding a permission.

Add the following **Microsoft Graph** permission:

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `User.Read` | Sign in and read user profile | No |

Add the following **Microsoft Purview** permission:

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `Purview.DelegatedAccess` | Purview Delegated API Access | No |

:::caution[Also requires Purview collection role assignments]
The permissions above only let the app call the API — the signed-in user also
needs Purview data-plane roles assigned on a collection in the [Microsoft
Purview governance portal](https://web.purview.azure.com/resource/) (**Data
Map** → **Collections** → select the root collection → **Role assignments**):

| Role | Grants |
| --- | --- |
| **Data Curator** | Catalog data plane — entities, glossary, lineage, relationships |
| **Data Source Administrator** | Scanning data plane — data sources, scans |
| **Collection Admin** | Account/metadata policy data plane — collections management |

Only members of the Collection Admin role can assign these roles.
:::

#### Microsoft Sentinel (Management)

Like Microsoft Defender for Cloud, this integration authenticates against
**Azure Resource Manager**, not Microsoft Graph. Add the following permission
instead of Microsoft Graph:

| API | Permission | Type | Admin consent required |
| --- | --- | --- | --- |
| Azure Resource Manager | `user_impersonation` | Delegated | No |

Find **Azure Resource Manager** under the **APIs my organization uses** tab
when adding a permission (App ID `797f4846-ba00-4fd7-ba43-dac1f8f63013`).

When linking the connection, Kindo also asks for:

| Field | Description |
| --- | --- |
| **Tenant ID** | App registration > Overview > Directory (tenant) ID |
| **Subscription ID** | The subscription holding the Sentinel workspace |
| **Resource Group Name** | The resource group holding the workspace |
| **Workspace Name** | The Log Analytics workspace Sentinel runs on |

All four are required — `Microsoft.SecurityInsights` has no tenant-level
surface to fall back on.

In addition to the Entra app permission, assign an Azure RBAC role to your
account on that workspace (Azure Portal > your workspace > **Access control
(IAM)** > Add role assignment):

| Role | Grants |
| --- | --- |
| **Microsoft Sentinel Reader** | All read tools (incidents, alerts, bookmarks, watchlists, analytics rules) |
| **Microsoft Sentinel Responder** | Everything Reader does, plus updating incidents and bookmarks |
| **Microsoft Sentinel Contributor** | Everything Responder does, plus creating and updating analytics rules and watchlists |

##### Microsoft Sentinel (Management) — US Government

Select the **Microsoft Sentinel Management (Government)** integration in Kindo
rather than **Microsoft Sentinel (Management)**, and create its app registration
in the Azure Government portal at [portal.azure.us](https://portal.azure.us). A
commercial app registration cannot be used.

Add the same permission, connection fields, and RBAC role as above.

#### Microsoft Teams

Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `Channel.ReadBasic.All` | Read the names and descriptions of channels | No |
| `ChannelMessage.Read.All` | Read user channel messages | Yes |
| `ChannelMessage.Send` | Send channel messages | No |
| `Chat.Create` | Create chats | No |
| `Chat.Read` | Read user chat messages | No |
| `Chat.ReadBasic` | Read names and members of user chat threads | No |
| `ChatMessage.Send` | Send user chat messages | No |
| `Files.Read.All` | Read all files that user can access | No |
| `Files.ReadWrite.All` | Have full access to all files user can access | No |
| `offline_access` | Maintain access to data you have given it access to | No |
| `OnlineMeetings.Read` | Read user's online meetings | No |
| `OnlineMeetingTranscript.Read.All` | Read all transcripts of online meetings. | Yes |
| `Team.ReadBasic.All` | Read the names and descriptions of teams | No |
| `User.Read` | Sign in and read user profile | No |
| `User.ReadBasic.All` | Read all users' basic profiles | No |

##### Microsoft Teams — meeting transcripts

:::caution[Permissions alone are not enough]
Microsoft Graph access to meeting transcripts is **off by default in every tenant**.
Until an admin turns it on, the transcript tools fail regardless of the permissions
granted above.
:::

In the Teams admin center, go to **Meetings** > **Meeting settings**. Under
**Transcript API access**, turn **Microsoft Graph access** **On**. Then select
**Configure** and turn on **Include speaker attribution**, so transcripts identify
who said what.

The PowerShell equivalent:

```powershell
Connect-MicrosoftTeams
Set-CsTeamsMeetingConfiguration -EnableGraphTranscriptAccess $true -EnableAttributedTranscripts $true -Identity Global
```

The setting is tenant-wide, not per user.

#### OneDrive

Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `Files.Read` | Read user files | No |
| `Files.Read.All` | Read all files that user can access | No |
| `Files.ReadWrite.All` | Have full access to all files user can access | No |
| `offline_access` | Maintain access to data you have given it access to | No |
| `User.Read` | Sign in and read user profile | No |

`Files.Read` only covers the signed-in user's own drive. Reading a drive by ID,
including a SharePoint document library, needs `Files.Read.All`.

#### SharePoint Online

Add the following **Microsoft Graph** permissions. All of them are **Delegated** permissions.

| Permission | Description | Admin consent required |
| --- | --- | --- |
| `Files.Read` | Read user files | No |
| `Files.ReadWrite` | Have full access to user files | No |
| `offline_access` | Maintain access to data you have given it access to | No |
| `Sites.Read.All` | Read items in all site collections | No |
| `Sites.ReadWrite.All` | Edit or delete items in all site collections | No |
| `User.Read` | Sign in and read user profile | No |

##### SharePoint Online — Application mode

Use the **SharePoint Online (Application)** integration in Kindo, with its own
app registration. Steps 1 to 4 apply unchanged.

Add `Sites.ReadWrite.All` as an **Application** permission and grant admin
consent. Skip Step 5 and the sign-in portion of Step 7: application mode needs
no redirect URI. Enter the Tenant ID alongside the client ID and secret in the
connection form.

## Step 7: Authorize and test

## Permission reference

Every tool across the Microsoft integrations, with the Microsoft permission it needs, whether it reads or writes, and whether an administrator has to consent. Use it to scope an app registration to exactly the tools you plan to use.

How to read the table:

- **Delegated** — the integration acts on behalf of a signed-in user. Every integration supports this mode.
- **Application** — the integration authenticates as the app itself, with no signed-in user. Only Microsoft Azure, Microsoft eDiscovery, Microsoft Entra ID, Microsoft Graph Security, Microsoft Intune, Microsoft Purview Compliance, and SharePoint Online offer it.
- **Admin consent** — Microsoft always requires tenant-wide admin consent for application permissions. The column shows the delegated requirement.
- **Roles** — rows labeled as a role are not Entra API permissions. Microsoft Azure, Microsoft Defender for Cloud, and Microsoft Sentinel (Management) authorize through Azure RBAC, and Microsoft Purview Data Governance through Purview collection roles. The signed-in user, or the app itself in application mode, must hold that role as well. Roles are assigned, not consented, so the admin consent column does not apply to them.
- A tool that needs more than one permission has one row per permission.

:::note
Microsoft grants most of these permissions at the API level rather than per operation, so several tools in an integration share one permission. Granting it enables every tool listed against it — check the access column for which of those can write.
:::

## Notes on service principals

If you look for an integration's app under **App registrations** and only find it under **Enterprise applications**, you are looking at its **service principal**.

- An **app registration** is the blueprint — the global definition of an application. It lives only in the tenant where the app was created.
- An **enterprise application** (service principal) is an instance of that blueprint inside each tenant that uses the app. It is the app's actual account in your directory.

What you see in your tenant depends on how you use Kindo:

- **Kindo SaaS:** the app registration lives in Kindo's tenant. The first time you authorize an integration, Entra ID creates a service principal in your tenant under **Enterprise applications**, and that is what you authenticate against on every subsequent connection. You will not see an app registration in your tenant.
- **Self-managed Kindo:** you create the app registration in your own tenant by following the steps on this page. When the app is first authorized, Entra ID still creates a matching service principal under **Enterprise applications**.

In both cases, the service principal is what Microsoft Entra ID uses to let the app operate in your tenant:

- **It holds the permission grants.** When a user or admin consents, the grant is recorded against the service principal. It is the ledger of what the app is allowed to access in your tenant.
- **It is the identity that tokens are issued to.** When Entra ID issues the app an access token for your tenant, the service principal is the actor that token represents.
- **It is your admin's control point.** Your admin manages the app under **Enterprise applications**: assign or restrict users, apply Conditional Access policies, disable the app, or revoke its access — all without touching the underlying registration.
- **It is where sign-in and audit activity lands.** Sign-in logs and consent events for the app in your tenant attach to the service principal.

## Troubleshooting

| Problem | What to check |
| --- | --- |
| Microsoft says the redirect URI is invalid | Make sure the redirect URI in Entra exactly matches the callback URL shown in Nango, including `https://` and `/oauth/callback`. |
| The consent screen does not show the expected permissions | Confirm the permissions were added to the same app registration whose client ID you entered in Nango. Reconnect after changing permissions. |
| Kindo reports `Unauthorized` or cannot refresh the connection | Recreate the connection and confirm the integration includes `offline_access` when delegated refresh is required. |
| Kindo reports `Forbidden` | The signed-in user may not have access to the Microsoft resource, admin consent may be missing, or the app may not have the required permission. |
| A write action fails but read actions work | The app may have read-only permissions. Add only the specific write permission required by the integration. |
| Microsoft eDiscovery (Application mode) reports `Unauthorized` | The app also needs to be registered in Microsoft Purview's RBAC layer — see [Application mode](#microsoft-ediscovery--application-mode). |
| Microsoft Graph Security risky-user tools report `access denied` | Requires a **Microsoft Entra ID P2** (or Microsoft 365 E5) license. |
| Microsoft Intune tools report `authentication failed` | Requires an active **Microsoft Intune** license. |
| Microsoft Defender tools report `access denied` | Requires an active **Microsoft Defender for Endpoint** subscription. |
| Microsoft Entra ID Governance's PIM or Lifecycle Workflows tools report a licensing error | PIM requires **Microsoft Entra ID P2**; Lifecycle Workflows requires the separate **Microsoft Entra ID Governance** license. |
| Microsoft Purview Data Governance tools report access errors even though the permissions are granted and admin-consented | The signed-in user is also missing a Purview collection role (Data Curator, Data Source Administrator, or Collection Admin) — see the Microsoft Purview Data Governance section above. |
| SharePoint Online (Application mode) site or file search reports `access denied` | The app holds `Sites.Selected`, which Microsoft does not support on these APIs. Grant `Sites.Read.All` or `Sites.ReadWrite.All` as an Application permission — see [Application mode](#sharepoint-online--application-mode). |

## Security guidance

- Use least-privilege permissions for every Microsoft integration.
- Rotate client secrets according to your organization's policy.
- Remove unused app registrations and old client secrets.
- Keep a record of which Kindo integration uses each Entra app registration.

## Related guides

- [Connect ServiceNow](/connecting-integrations/servicenow/)

---

## Invoke Kindo agents with the Responses API

Source: https://docs.kindo.ai/guides/invoke-agents-responses-api/

Every agent you build in Kindo is invocable through
`POST /v1/responses` by passing its ID as the model:

```json
{ "model": "agent/8e051857-978c-4207-8916-28a3d4c4d605", "input": "..." }
```

The agent supplies the model, system prompt, and tools; you supply
the task. Because `model` is a field every OpenAI Responses client
can set, this works from stock SDKs with no code changes — the same
clients you already point at `api.kindo.ai`.

This page takes you from zero to a streamed agent run.

## What you need

1. **A Kindo API key** — see [Authentication](/overview/authentication/).
2. **Your agent's ID.** Two ways to find it:

   ```bash
   # Alongside your model catalog (agents appear as agent/<agent-id>)
   curl "https://api.kindo.ai/v1/models?include_agents=true" \
     -H "Authorization: Bearer $KINDO_API_KEY"

   # Or from the agents list (returns agentId per agent)
   curl https://api.kindo.ai/v1/agents/list \
     -H "Authorization: Bearer $KINDO_API_KEY"
   ```

   You can also copy the agent ID from its URL in the Kindo Terminal.

## Invoke the agent

### openai-python

```python

from openai import OpenAI

client = OpenAI(
    base_url="https://api.kindo.ai/v1",
    api_key=os.environ["KINDO_API_KEY"],
)

response = client.responses.create(
    model="agent/8e051857-978c-4207-8916-28a3d4c4d605",
    input="Triage INC-4821 and propose a remediation plan.",
    instructions="Keep the summary to one sentence.",  # optional — appends after the agent's own prompt
)

print(response.id, response.status)
# resp_run_04f0faa6-2e66-4f5a-b49f-6a28daa58d9b in_progress
```

### curl

```bash
curl -X POST https://api.kindo.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "model": "agent/8e051857-978c-4207-8916-28a3d4c4d605",
    "input": "Triage INC-4821 and propose a remediation plan."
  }'
```

The call returns **immediately** with an in-progress response —
agent runs are long-horizon, so you stream or poll rather than block:

```json
{
  "id": "resp_run_04f0faa6-2e66-4f5a-b49f-6a28daa58d9b",
  "object": "response",
  "status": "in_progress",
  "model": "agent/8e051857-978c-4207-8916-28a3d4c4d605",
  "output": [],
  "conversation": { "id": "conv_cmqbjvxqv000001ac25z0pje6" },
  "metadata": {
    "kindo_run_id": "04f0faa6-2e66-4f5a-b49f-6a28daa58d9b",
    "kindo_agent_id": "8e051857-978c-4207-8916-28a3d4c4d605"
  }
}
```

### How your request composes with the agent

- `input` — delivered to the run. If the agent declares exactly one
  named text input, your text binds to it; if it declares none, your
  text becomes the run conversation's opening user message (visible
  context for every step). Agents with two or more named inputs — or
  a single non-text input — cannot take freeform input
  (`400 agent_inputs_unmappable`); use
  [`POST /v1/agents/runs`](/apis/agents/runs/) with named inputs.
- `instructions` — optional; appended **after** the agent's own
  system prompt.
- `metadata` — echoed back, merged with the run linkage keys.
- Everything pinned by the agent's stored configuration (`tools`,
  non-`"auto"` `tool_choice`, sampling parameters, `conversation`,
  `previous_response_id`, `background`) is rejected with
  `400 unsupported_parameter` naming the field — nothing is silently
  dropped.

## Stream the run live

Set `stream: true` to watch the run as it progresses. The run's
activity streams as standard Responses output items — assistant text
as live `response.output_text.delta` events, plus reasoning summaries
and tool-call items as each step executes:

```bash
curl -N -X POST https://api.kindo.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "model": "agent/8e051857-978c-4207-8916-28a3d4c4d605",
    "input": "Triage INC-4821 and propose a remediation plan.",
    "stream": true
  }'
```

```
event: response.created
event: response.in_progress
event: response.output_item.added      ← message / reasoning / tool-call
event: response.output_text.delta         items, streamed live as each
event: response.output_text.done          step of the run executes
event: response.output_item.done
...
event: response.completed              ← carries the full final response
data: [DONE]
```

Notes on stream semantics:

- Steps stream **live, at item granularity**. Assistant text arrives
  as `response.output_text.delta` events; reasoning summaries stream
  as `response.reasoning_summary_text.delta`; tool activity appears
  as typed items (`mcp_call`, `kindo_call`, `shell_call`,
  `web_search_call`) with their own argument-delta events. See
  [Streaming](/apis/responses/streaming/) for the event vocabulary.
- A step that already finished before you connected is replayed as
  completed items (`response.output_item.added` +
  `response.output_item.done` pairs) rather than re-streamed
  token-by-token.
- A failed run ends with `response.failed`; a run cancelled from the
  Kindo Terminal ends with an `error` event (`code: "run_cancelled"`).
  Every terminal path is followed by `data: [DONE]`.
- Streams are capped at 30 minutes (`error` / `code: "stream_timeout"`).
  The run itself keeps executing — switch to polling below.
- If you disconnect, nothing is lost: the run continues server-side
  and remains pollable. To re-attach to the stream, reconnect with
  `GET /v1/responses/{id}?stream=true` — agent-run responses replay
  from the beginning and then continue live (see
  [Streaming → resuming](/apis/responses/streaming/#agent-run-responses-replay-from-the-start-only)).

## Poll to completion (non-streaming)

Without `stream: true`, take the `id` from the immediate response and
poll `GET /v1/responses/{id}` until the status is terminal:

```python

response = client.responses.create(
    model="agent/8e051857-978c-4207-8916-28a3d4c4d605",
    input="Triage INC-4821 and propose a remediation plan.",
)

while response.status == "in_progress":
    time.sleep(3)
    response = client.responses.retrieve(response.id)

print(response.status)       # completed | failed | cancelled
print(response.output_text)  # the run's final answer
```

```bash
curl https://api.kindo.ai/v1/responses/resp_run_04f0faa6-2e66-4f5a-b49f-6a28daa58d9b \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

Statuses: `in_progress` → `completed`, `failed`, or `cancelled`.

## Read the output

The response carries the run's activity as standard Responses output
items — populated incrementally while the run is `in_progress`, and
complete on a terminal status:

- `output` — the run's assistant turns as output items: `message`
  items with `output_text` content, `reasoning` summaries, and tool
  activity (`mcp_call`, `kindo_call`, `shell_call`,
  `web_search_call`) where present.
- `output_text` — the concatenated final answer text.
- `usage` — token usage aggregated across the run.
- `metadata.kindo_run_id` / `metadata.kindo_agent_id` — run linkage.
  The run ID also works with
  [`GET /v1/runs/{runId}`](/apis/agents/runs/) if you already
  integrate with the agents API.
- `conversation.id` — the run's conversation. Read the full
  step-by-step transcript with
  [`GET /v1/conversations/{id}/items`](/apis/conversations/quickstart/).

## Current limitations

Stated plainly, so you can design around them today:

- **No request `tools` on agent models.** The agent's tool set is
  pinned by its configuration; additive request tools are planned.
- **No `conversation` / `previous_response_id` on agent models**, and
  agent-run response IDs (`resp_run_*`) are not chainable via
  `previous_response_id` (you get `404 previous_response_not_found`).
  Conversation continuity for agent runs — follow-up turns to the
  same run conversation — is upcoming.
- **Version pinning is not available yet.** `agent/<id>@<version>`
  returns `400 agent_version_pinning_unsupported`; invocations always
  run the agent's latest configuration.
- **Freeform `input` binds to at most one text input.** An agent that
  declares two or more named inputs — or a single non-text input —
  returns `400 agent_inputs_unmappable`; run it with
  [`POST /v1/agents/runs`](/apis/agents/request-shape/#post-v1agentsruns)
  and named inputs instead.

## Errors

| Status | Code                                  | Meaning                                                                                                   |
| ------ | ------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| `400`  | `model_not_found`                     | Unknown, malformed, **or inaccessible** agent ID — indistinguishable from an unknown model on purpose.    |
| `400`  | `agent_version_pinning_unsupported`   | `agent/<id>@<version>` — drop the version suffix.                                                          |
| `400`  | `agent_inputs_unmappable`             | The agent declares 2+ named inputs, or a single non-text input — use [`POST /v1/agents/runs`](/apis/agents/runs/). |
| `400`  | `unsupported_parameter`               | A request field conflicts with the agent's pinned configuration; the message names the field.              |
| `404`  | `previous_response_not_found`         | You passed a `resp_run_*` ID (or any non-stored response ID) as `previous_response_id`.                    |
| `404`  | `not_found`                           | `GET /v1/responses/resp_run_*` for a run that doesn't exist or that you cannot access.                     |

All errors use the standard
[Responses error envelope](/apis/responses/errors/).

## See also

- [Responses API quickstart](/apis/responses/quickstart/) — point your
  SDK at Kindo.
- [Request shape](/apis/responses/request-shape/#agent-models-agentagent-id) —
  `agent/<agent-id>` in the field reference.
- [Model catalog](/overview/model-catalog/#listing-agents-as-models) —
  discover agents with `include_agents=true`.
- [Agents API](/apis/agents/quickstart/) — the control-plane surface
  (list agents, named-input runs, run results).

---

## Exercise B - Universal Security Triage Agent

Source: https://docs.kindo.ai/learning/customer-training-session/exercises/universal-triage-agent/

## Exercise Metadata

| Field | Value |
| --- | --- |
| Duration | ~35 minutes |
| Type | Workflow Agent with Integrations |
| Focus | Agentic tool calling across security stack |

:::tip
This is the star exercise for the session: one runbook prompt, one LLM step, five tools, autonomous investigation flow.
:::

## Scenario

SOC analysts often pivot across SIEM, EDR, identity, firewall, and threat-intel tools manually. That process can take 30-60 minutes per alert and delays incident response during alert volume spikes.

## Objective

Build a single-step Kindo Workflow Agent that performs end-to-end triage across the security stack and synthesizes a justified disposition.

The agent should autonomously:

- Extract entities from an alert (users, hosts, IPs, domains, hashes, processes)
- Query SIEM for correlated events and timelines
- Query EDR for endpoint context and process activity
- Query IdP for sign-in and privilege anomalies
- Query firewall/NDR for network anomalies and beaconing
- Enrich IOCs with threat intelligence
- Produce a final disposition and ranked action plan

## What Makes This Exercise Different

| Exercise A | Exercise B |
| --- | --- |
| Multi-step prompts for fixed workflow stages | Single-step runbook prompt |
| Agent follows explicit sequence | Agent decides which tool to call and when |
| Demonstrates structured procedural automation | Demonstrates agentic reasoning |
| Primary tool: Knowledge Store | Primary tools: live integrations |

## Integrations Used (Demo Mode)

| Integration | Role | What the Agent Queries |
| --- | --- | --- |
| Splunk | SIEM | Alerts, correlated events, timeline |
| CrowdStrike | EDR | Endpoint detections, device context, process trees |
| Okta | IdP | Sign-in events, MFA status, privilege changes |
| Palo Alto | Firewall/NDR | Network traffic, beaconing, lateral movement |
| VirusTotal | Threat Intel | IOC reputation, file analysis, domain/IP enrichment |

:::note
Demo Mode uses synthetic but coherent cross-tool data so correlations are realistic while avoiding production credentials.
:::

## Prerequisites

- Kindo training account
- Five integrations pre-enabled by session facilitator
- Demo Mode enabled in training environment

## Step 1 - Create Agent and Enable Integrations (5 min)

{/* Screenshot placeholder: Integrations panel showing all five tools toggled on */}

:::tip
This setup is the key differentiator from a standalone LLM: the model can actually call security tools instead of only analyzing pasted text.
:::

## Step 2 - Add the Triage Runbook Prompt (10 min)

Add one LLM step named `Triage Runbook` and use this prompt:

```plaintext
Run an end-to-end triage on the triggering alert/ticket if present. If no trigger exists, triage the highest-severity SIEM alerts from the last 4 hours.

1) Extract entities from the triggering object (users, hosts, IPs, domains, hashes, processes, email IDs, cloud resources).

2) SIEM: pull the rule details, raw events, correlations, first/last seen timestamps, and related alerts.

3) EDR/XDR: check device posture, detections, process tree, network connections, persistence mechanisms, and lateral movement signs.

4) IdP/IAM: review sign-in timeline, MFA outcomes, risk events, session/token anomalies, and privilege changes.

5) Firewall/NDR: check DNS + outbound anomalies, beaconing patterns, and east-west traffic spikes.

6) Threat Intel: enrich all IOCs (hashes, IPs, domains) and link to known campaigns or threat groups.

Conclude with:
- Disposition: TRUE POSITIVE / FALSE POSITIVE / NEEDS MORE DATA
- Severity: CRITICAL / HIGH / MEDIUM / LOW
- Confidence: HIGH / MEDIUM / LOW (with explanation)
- Scope: contained to single host | multiple hosts | org-wide | unknown
- Evidence summary: one line per data source showing what it found and whether it supports TP or FP
- Attack narrative (if TP): initial access -> current stage -> blast radius
- Ranked next steps: containment -> evidence preservation -> further investigation -> notification -> remediation
```

:::note
Why one step: in this pattern, you define goal + tool access + output contract. The model determines call order dynamically from findings.
:::

## Step 3 - Run, Observe, and Review (15 min)

Typical execution path you may observe:

- Splunk queried for alert baseline and entities
- CrowdStrike queried for host/process context
- Okta queried for user authentication timeline
- Palo Alto queried for network behavior linked to entities
- VirusTotal queried for IOC enrichment
- Final synthesis into disposition and actions

### Review Checklist

- Disposition quality: verdict is evidence-backed and coherent
- Tool sequence quality: calls are relevant and follow-up queries are logical
- Cross-correlation quality: findings are connected across identity, endpoint, and network data
- Action quality: next steps are prioritized and operationally useful

:::caution
Flag low-quality output when confidence is high but evidence is missing, contradictory findings are ignored, or recommendations are generic.
:::

## Step 4 (Optional) - Add One Real Integration (5 min)

If credentials are available, connect one real integration and rerun. This demonstrates production connection flow while preserving demo data for the remaining tools.

## Discussion Points

- Agentic versus procedural design: when should each be used?
- Did the agent make unnecessary calls or miss useful ones?
- How did multi-source correlation improve triage quality?
- If this saves 30-60 minutes per alert, where should that analyst time be reinvested?

## Production Extensions

- Trigger triage automatically for high-severity SIEM alerts
- Auto-create Jira or ServiceNow tickets for true positives
- Notify Slack on CRITICAL findings
- Re-triage open incidents on a recurring schedule as new evidence arrives

## Troubleshooting

| Issue | Likely Cause | How To Fix |
| --- | --- | --- |
| Agent does not call all integrations | Integration toggles are disabled or unavailable | Re-check integration enablement in agent settings |
| Output contains unsupported claims | Prompt missing evidence accountability | Keep required evidence summary lines per data source |
| Agent loops or over-queries one source | Runbook lacks prioritization guardrails | Add guidance: stop querying once confidence threshold is met |
| Disposition stays NEEDS MORE DATA | Entities not extracted or source data sparse | Add explicit entity extraction checks and broaden time window |
| Contradictory evidence not reconciled | Prompt lacks conflict-handling instruction | Add requirement to explain contradictions before verdict |

## Continue

- Return to [Session Overview](/learning/customer-training-session/)
- Open [Prompt Engineering Quick Reference](/reference/prompt-engineering/)
- Open [Agent Construction Best Practices](/reference/agent-best-practices/)

---

## Authentication

Source: https://docs.kindo.ai/overview/authentication/

A single Kindo API key authenticates every API on `api.kindo.ai` —
inference (`/v1/chat/completions`, `/v1/responses`, `/v1/messages`,
`/v1/mcp`) and control plane (`/v1/agents/*`, `/v1/runs/*`,
`/v1/conversations/*`, `/v1/models`, `/v1/integrations/*`). There are
no per-API credentials.

`/v1/mcp` also accepts a [Cross App Access](/admin/cross-app-access/)
token in place of an API key — a beta credential, enabled per
organization, that lets an Okta-approved app call the MCP gateway on a
user's behalf without a Kindo API key. It isn't governed by **Personal
API Key Access**.

## Get your API key

1. Sign in to the Kindo Terminal.
2. Open [**Settings** (gear icon) > **API**](https://app.kindo.ai/?settings=api/api-keys).
3. Copy your API key.

If you do not see the API tab, ask your organization admin to
enable **Personal API Key Access** for at least one user group you
belong to. Self-managed deployments expose the same key in the same
place; only the base URL differs.

A key **acts as you, its creator**: every request it makes runs with
your identity, and all activity — including the audit trail — is
attributed to you and carries your permissions.

## Send the key

Both header forms work on every Kindo API:

| Header                  | Example                              | Notes                                                                                     |
| ----------------------- | ------------------------------------ | ----------------------------------------------------------------------------------------- |
| `Authorization: Bearer` | `Authorization: Bearer YOUR_API_KEY` | Preferred for raw HTTP clients and for the OpenAI SDKs (`OPENAI_API_KEY` populates this). |
| `x-api-key`             | `x-api-key: YOUR_API_KEY`            | Preferred for Anthropic SDKs and Claude Code (`ANTHROPIC_API_KEY` populates this).        |

Pick whichever is idiomatic for the client you're using — both
authenticate the same way and resolve to the same caller identity.

### Precedence

If both headers are present on a single request, **`Authorization: Bearer`
takes precedence**. If the `Authorization` header is present but
malformed (for example, an empty token, or a non-Bearer scheme like
`Basic`), the request is rejected outright instead of falling back to
`x-api-key`.

## Key format

Kindo API keys are opaque strings. Treat them as secrets:

- Store them in your secret manager (1Password, Doppler, AWS Secrets
  Manager, Vault).
- Inject them at runtime via environment variables.
- Never commit them to source control.
- Rotate them through the Kindo Terminal if you suspect exposure.

## Identity and permissions

An API key acts as its creating user — that user is the key's
**principal**. Every request authenticated with the key runs as that
user, and every audit entry the request produces is attributed to
that user. The key is not a separate service identity; it carries the
identity and the permissions of the person who created it.

Because the key inherits the permissions of the user who created it:

- **Model and provider access** restrictions configured on the user's
  user groups apply to API requests.
- **Personal API Key Access** must be enabled on at least one user
  group the user belongs to.
- **Ask Mode Only** is enforced on `/v1/responses`.
- DLP filters that protect the Terminal UI also apply to API
  requests.
- All API calls are recorded in your organization's audit trail.

## Self-managed deployments

For self-managed Kindo installations, replace `api.kindo.ai`
everywhere with your deployment's API base URL. Header semantics,
key format, and identity rules are unchanged.

## Errors

| Status | Meaning                                                                                      |
| ------ | -------------------------------------------------------------------------------------------- |
| `401`  | The key was missing, malformed, or revoked. Check your `Authorization` / `x-api-key` header. |
| `403`  | The key authenticated, but lacks permission for the model.                                   |

Each protocol formats the error envelope differently — see the
per-API errors page (`/apis/<protocol>/errors/`) for shapes.

## See also

- [Getting started](/overview/getting-started/) — pick your client.
- [Model catalog](/overview/model-catalog/) — discover available
  model IDs once authenticated.

---

## Agents API runs

Source: https://docs.kindo.ai/apis/agents/runs/

`POST /v1/agents/runs` is asynchronous. The trigger returns
immediately with a `runId`; the result lands on
`GET /v1/runs/{runId}` when the run finishes.

## `GET /v1/runs/{runId}`

```bash
curl https://api.kindo.ai/v1/runs/7a7ced7d-95a8-416f-95bb-5c0ff3599f53 \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

Response:

```json
{
  "runId": "7a7ced7d-95a8-416f-95bb-5c0ff3599f53",
  "agentId": "18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d",
  "conversationId": "clx9a2b1c0000d4e5f6g7h8i9",
  "createdAtUtc": "2026-03-12T15:00:00.000Z",
  "endedAtUtc": "2026-03-12T15:00:08.000Z",
  "result": "{\"role\":\"assistant\",\"parts\":[{\"type\":\"text\",\"text\":\"Security scan complete. No critical findings.\"}]}",
  "status": "success"
}
```

| Field            | Type           | Notes                                                                                                                                                                                                                                                                                                                             |
| ---------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `runId`          | string         | Matches the `runId` returned by the trigger.                                                                                                                                                                                                                                                                                      |
| `agentId`        | string \| null | The agent that produced this run. `null` when the underlying agent has been soft-deleted; the run record remains visible but no longer resolves to a live agent.                                                                                                                                                                  |
| `conversationId` | string \| null | The conversation backing this run. Pass it to [`GET /v1/conversations/{conversation_id}/items`](/apis/conversations/quickstart/) to read the full message history — useful for multi-turn continuity. Always present in practice today; typed as nullable for forward compatibility, so defensive clients should tolerate `null`. |
| `createdAtUtc`   | string         | ISO-8601 timestamp when the trigger was accepted.                                                                                                                                                                                                                                                                                 |
| `endedAtUtc`     | string \| null | ISO-8601 timestamp when the run reached a terminal status, or `null` while `status` is `in_progress`.                                                                                                                                                                                                                             |
| `result`         | string \| null | A **JSON-encoded string** of the final assistant message payload — parse with `JSON.parse` to recover `{ role, parts, ... }`. `null` while `in_progress`, always `null` on `failure` or `cancelled`, and also `null` on `success` when the run produced no assistant payload.                                                     |
| `status`         | string         | One of `in_progress`, `success`, `failure`, `cancelled`.                                                                                                                                                                                                                                                                          |

## Status lifecycle

```text
in_progress  ──▶  success
             ──▶  failure     ──▶  in_progress   (re-run failed step)
             ──▶  cancelled
```

`failure` is not a permanent sink: re-running the failed step from the
Kindo app returns the run to `in_progress` (see the `failure` note below).

- `in_progress` — the only non-terminal status. Continue polling.
- `success` — the run completed; `result` holds the JSON-encoded
  final assistant payload, or is `null` if the run produced no
  assistant payload.
- `failure` — the run errored. `result` is `null`; inspect the
  Kindo Terminal or the underlying conversation for diagnostics.
  A `failure` run is not permanently terminal: a user can re-run the
  failed step from the Kindo app, which returns the same run to
  `in_progress` (and resets `endedAtUtc` to `null`) until it reaches
  a terminal status again.
- `cancelled` — the run was cancelled (manually or by a timeout).
  `result` is `null`.

## `POST /v1/runs/{runId}/restart`

Re-runs a previous run by its `runId` — handy for retrying a run that
`failed` — without re-sending the original inputs. Like the trigger,
the call is asynchronous and returns immediately with a **new**
`runId`; poll `GET /v1/runs/{newRunId}` for its result.

```bash
curl -X POST https://api.kindo.ai/v1/runs/7a7ced7d-95a8-416f-95bb-5c0ff3599f53/restart \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

Response (`202 Accepted`):

```json
{
  "runId": "b2f1c0a9-6e3d-4f28-9a17-2d4e8c1b7f60",
  "conversationId": "clx9a2b1c0000d4e5f6g7h8i9"
}
```

| Field            | Type   | Notes                                                                                                                                                    |
| ---------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `runId`          | string | The **new** run's id — distinct from the run you restarted. Track and poll it the same way you would a freshly triggered run.                            |
| `conversationId` | string | The conversation backing the new run. Pass it to [`GET /v1/conversations/{conversation_id}/items`](/apis/conversations/quickstart/) to read its history. |

Notes:

- No request body is required, and none is read — the new run re-uses
  the source run's original inputs as they were first submitted.
- The source run is left untouched; the returned `runId` is a separate
  run with its own status, result, and conversation.
- The new run uses the agent's **latest** version, so its behavior can
  differ from the source run if the agent was edited in between.
- Returns `404` when the run does not exist or the caller lacks access
  — the same collapse-to-404 behavior as `GET /v1/runs/{runId}`.

## `GET /v1/runs/{runId}/evals`

Returns the aggregate evaluation result and per-step verdicts for a
run — including runs that failed or were cancelled partway, which
surface a `partial` result for the steps that were evaluated. Each
agent step can have an objective; this endpoint reports whether those
objectives were met.

```bash
curl https://api.kindo.ai/v1/runs/7a7ced7d-95a8-416f-95bb-5c0ff3599f53/evals \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

Response:

```json
{
  "runId": "7a7ced7d-95a8-416f-95bb-5c0ff3599f53",
  "result": "fail",
  "steps": [
    {
      "stepNumber": 1,
      "name": "Perform Web Search for Trending Stock",
      "result": "pass",
      "explanation": "Kindo performed web searches and synthesized findings into a clear summary."
    },
    {
      "stepNumber": 2,
      "name": "Generate Stock Forecast",
      "result": "pass",
      "explanation": "Kindo delivered a comprehensive forecast with analyst targets and risk factors."
    },
    {
      "stepNumber": 3,
      "name": "Execute Trade on Robinhood",
      "result": "fail",
      "explanation": "Kindo cannot execute trades on Robinhood — it lacks brokerage integration."
    }
  ]
}
```

| Field    | Type   | Notes                                                                                                                                                                                                                                                                                                                                                                                                         |
| -------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `runId`  | string | Matches the `runId` from the trigger.                                                                                                                                                                                                                                                                                                                                                                         |
| `result` | string | Aggregate eval result. One of `pass`, `fail`, `partial`, `pending`, `skipped`, `unknown`. `pass` = all objectives satisfied; `fail` = at least one failed; `partial` = run failed/cancelled but some completed steps were evaluated (inspect `steps[]`); `pending` = run in progress or verdicts not yet written; `skipped` = run failed/cancelled with no evaluated steps; `unknown` = no definitive result. |
| `steps`  | array  | One entry per step in the run, ordered by `stepNumber`.                                                                                                                                                                                                                                                                                                                                                       |

Step shape:

| Field         | Type           | Notes                                                                                                                                                                                                                                                              |
| ------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `stepNumber`  | integer        | 1-indexed position in the run.                                                                                                                                                                                                                                     |
| `name`        | string \| null | Display name of the step, or `null` if unnamed.                                                                                                                                                                                                                    |
| `result`      | string \| null | One of `pass`, `fail`, `not_evaluated`, `unknown`, or `null`. `pass` = objective satisfied; `fail` = objective not satisfied; `not_evaluated` = evaluation did not run; `unknown` = verdict could not be determined. `null` when no verdict has been recorded yet. |
| `explanation` | string \| null | Free-form explanation of the verdict; `null` when not evaluated.                                                                                                                                                                                                   |

The evals endpoint returns `404` when the run does not exist or the
caller lacks access — the same collapse-to-404 behavior as
`GET /v1/runs/{runId}`.

### Result values and what produces them

| `result` (aggregate) | Meaning                                                           | When it arises                                                                                                                                                                                                    |
| -------------------- | ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `pass`               | All evaluated objectives satisfied.                               | Run reached `success`, every evaluated step verdict is satisfied.                                                                                                                                                 |
| `fail`               | At least one objective was not satisfied.                         | Any step verdict is "not satisfied".                                                                                                                                                                              |
| `pending`            | Evaluation not finished yet.                                      | Run still `in_progress`, or at least one step verdict has not been written.                                                                                                                                       |
| `partial`            | The run did not complete, but some steps that ran were evaluated. | Run ended in `failure` or `cancelled` **and** at least one completed step has a verdict. Inspect `steps[]` for the per-step results; the run never reached `success`, so no clean pass/fail aggregate is claimed. |
| `skipped`            | Evaluation did not run for any step.                              | Run ended in `failure` or `cancelled` with no evaluated steps, or no step had an objective to evaluate.                                                                                                           |
| `unknown`            | Verdicts exist but no definitive aggregate could be determined.   | A verdict could not be determined for a step (and no step failed).                                                                                                                                                |

The step-level `result` distinguishes two superficially similar cases:

- `not_evaluated` — the step had no objective evaluation performed (the
  step itself recorded a "not evaluated" verdict).
- `unknown` — an evaluation was attempted but the verdict could not be
  determined.
- `null` — no verdict has been recorded for the step yet (see the async
  section above); this is transient.

### Error responses

| Status | Condition                                                                           | Body shape                                                                 |
| ------ | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| `400`  | `runId` is malformed (not a UUID).                                                  | `{ "error": "Bad Request", "message": "..." }`                             |
| `401`  | Missing or invalid API key.                                                         | `{ "error": "Unauthorized", "message": "..." }`                            |
| `404`  | Run does not exist **or** the caller lacks access (deliberately not distinguished). | `{ "error": "Not found", "message": "Run <runId> not found." }`            |
| `500`  | Unexpected server-side error. Transient — retry with backoff.                       | `{ "error": "Internal Server Error", "message": "Something went wrong." }` |

Example `404`:

```json
{
  "error": "Not found",
  "message": "Run 7a7ced7d-95a8-416f-95bb-5c0ff3599f53 not found."
}
```

Example `500`:

```json
{
  "error": "Internal Server Error",
  "message": "Something went wrong."
}
```

### What to expect on failure

| Condition                                       | Transient? | Client action                                                                 |
| ----------------------------------------------- | ---------- | ----------------------------------------------------------------------------- |
| `result: "pending"` / step `result: null`       | Yes        | Keep polling with backoff.                                                    |
| `result: "partial"` (run `failure`/`cancelled`) | No         | `cancelled` is terminal; a `failure` run can be re-run from the Kindo app (returns to `in_progress`). Read `steps[]` for the verdicts of the steps that completed. |
| `500`                                           | Yes        | Retry with backoff; evals are idempotent.                                     |
| `400` (malformed `runId`)                       | No         | Fix the request; do not retry as-is.                                          |
| `401`                                           | No         | Provide a valid API key; do not retry as-is.                                  |
| `404`                                           | No         | The run is missing or inaccessible; do not retry as-is.                       |

There are no webhooks for evaluation completion — polling is the only
mechanism. Re-fetching evals is always safe.

## Polling cadence

Runs are typically long-running (seconds to minutes), so a short
poll-then-back-off works well in practice:

- Wait 1–2 seconds before the first poll.
- Back off to 5–10 seconds for subsequent polls.
- Treat any non-`in_progress` `status` as terminal and stop. If you
  re-read a `failure` run later, it may have returned to
  `in_progress` because a user re-ran the failed step from the
  Kindo app.

Kindo does not currently push webhooks for run completion; polling
is the only delivery mechanism for the result.

## Runs and conversations

Every run is backed by its own server-side `conversation`. The
`runId` itself is not a `conversation_id`, but the `conversationId`
is returned directly on both the `POST /v1/agents/runs` trigger
response and the `GET /v1/runs/{runId}` run-result response. Pass it
to the [Conversations API](/apis/conversations/quickstart/)
(`GET /v1/conversations/{conversation_id}/items`) to read the full
message history — the basis for multi-turn continuity across runs.
For most use cases, `result` on `GET /v1/runs/{runId}` is the only
field you need.

## See also

- [Quickstart](/apis/agents/quickstart/) — end-to-end discover → trigger → poll flow.
- [Request shape](/apis/agents/request-shape/) — the trigger and discovery bodies.
- [Errors](/apis/agents/errors/) — `404 Not found`, `422 Unprocessable Entity`, etc.

---

## Chat Completions API streaming

Source: https://docs.kindo.ai/apis/chat-completions/streaming/

Set `"stream": true` on `POST /v1/chat/completions` to receive a
standard OpenAI Server-Sent Events stream. Your existing parser
works unchanged.

## Request

```bash
curl -N https://api.kindo.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "model": "claude-sonnet-4-5-20250929",
    "stream": true,
    "messages": [
      { "role": "user", "content": "Write a haiku about observability." }
    ]
  }'
```

Kindo returns `Content-Type: text/event-stream` and emits OpenAI's
chunk format. Each event is a JSON payload prefixed with `data: `:

```
data: {"id":"chatcmpl-abc123","object":"chat.completion.chunk","choices":[{"delta":{"role":"assistant","content":""}}]}

data: {"id":"chatcmpl-abc123","object":"chat.completion.chunk","choices":[{"delta":{"content":"Logs flow through"}}]}

data: {"id":"chatcmpl-abc123","object":"chat.completion.chunk","choices":[{"delta":{"content":" the gate;"}}]}

data: {"id":"chatcmpl-abc123","object":"chat.completion.chunk","choices":[{"delta":{},"finish_reason":"stop"}]}

data: [DONE]

```

The terminal `data: [DONE]` line is the canonical end-of-stream
marker.

## Event types

The stream emits unnamed `data:` lines. Each line is either an incremental chunk or the terminal marker:

| Event    | Meaning                                           |
| -------- | ------------------------------------------------- |
| `data:`  | Incremental `chat.completion.chunk` JSON payload. |
| `[DONE]` | End-of-stream marker.                             |

## Example stream

Each `data:` JSON object follows OpenAI's `chat.completion.chunk`
schema:

```json
{
  "id": "chatcmpl-abc123",
  "object": "chat.completion.chunk",
  "created": 1710000000,
  "model": "claude-sonnet-4-5-20250929",
  "choices": [
    {
      "index": 0,
      "delta": { "content": " the gate;" },
      "finish_reason": null
    }
  ]
}
```

`usage` is not included in intermediate chunks. In the OpenAI spec,
`stream_options.include_usage` requests usage data in the final
chunk; Kindo currently does not populate this field. If you need
usage stats, make a non-streaming request or rely on Kindo's metering.

## SDK consumption

```python

from openai import OpenAI

client = OpenAI(base_url="https://api.kindo.ai/v1", api_key=os.environ["KINDO_API_KEY"])

stream = client.chat.completions.create(
    model="claude-sonnet-4-5-20250929",
    messages=[{"role": "user", "content": "Write a haiku."}],
    stream=True,
)

for chunk in stream:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
```

```ts

const client = new OpenAI({
  baseURL: 'https://api.kindo.ai/v1',
  apiKey: process.env.KINDO_API_KEY
});

const stream = await client.chat.completions.create({
  model: 'claude-sonnet-4-5-20250929',
  messages: [{ role: 'user', content: 'Write a haiku.' }],
  stream: true
});

for await (const chunk of stream) {
  process.stdout.write(chunk.choices[0].delta.content ?? '');
}
```

## Pre-stream errors

If the upstream request fails before streaming begins, Kindo returns
a normal HTTP error response with the OpenAI-compatible JSON
envelope — no SSE switch. See [Errors](/apis/chat-completions/errors/).

## Mid-stream errors

Once SSE has started, the outer HTTP status is committed at `200`.
Errors that arise after that point arrive as an inline `event: error`
SSE frame followed by `data: [DONE]`:

```
event: error
data: {"error":{"message":"upstream stream interrupted","type":"server_error","code":"stream_error"}}

data: [DONE]

```

Treat any `event: error` payload with `code: "stream_error"` as
terminal — the response will not resume.

## See also

- [Quickstart](/apis/chat-completions/quickstart/) — non-streaming round trip.
- [Request shape](/apis/chat-completions/request-shape/) — every field Kindo honors.
- [Tool use](/apis/chat-completions/tool-use/) — streaming tool-call events.
- [Errors](/apis/chat-completions/errors/) — pre-stream error envelopes.

---

## Conversations API errors

Source: https://docs.kindo.ai/apis/conversations/errors/

The Conversations endpoints return errors in OpenAI's **nested**
error envelope — the same shape as the OpenAI Conversations and
Responses APIs. This is intentionally different from the
[Agents API](/apis/agents/errors/), which uses a flat
`{ "error": string, "message": string }` envelope.

## Envelope

```json
{
  "error": {
    "message": "Conversation not found.",
    "type": "not_found_error",
    "code": "not_found"
  }
}
```

## Status / type / code reference

| Status | `type`                  | `code`           | Cause                                                                                                                                                                                                                                                                                             |
| ------ | ----------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `400`  | `invalid_request_error` | `invalid_cursor` | `?after=` references an item that does not exist in this conversation.                                                                                                                                                                                                                            |
| `401`  | —                       | —                | Missing, malformed, or revoked API key. Emitted by the auth middleware **before** the route handler runs, so the body is the flat `{"error": "Unauthorized", "message": "..."}` shape — not the nested envelope shown above. |
| `403`  | `permission_error`      | `forbidden`      | The key authenticated, but the caller does not have access to this conversation.                                                                                                                                                                                                                  |
| `404`  | `not_found_error`       | `not_found`      | `conversation_id` or `item_id` does not exist, or the conversation has been pruned by retention.                                                                                                                                                                                                  |
| `413`  | —                       | —                | JSON request body exceeds the 50 MB (52,428,800-byte) limit. Returned before route handling as `{"message":"Request body too large. Maximum size is 50 MB."}`.                                                                                                                                |

## See also

- [Quickstart](/apis/conversations/quickstart/) — list + fetch flow.
- [Request shape](/apis/conversations/request-shape/) — query parameters and item types.
- [Agents API errors](/apis/agents/errors/) — Kindo's other agent
  surface, which uses a different (flat) envelope.

---

## MCP API request shape

Source: https://docs.kindo.ai/apis/mcp/request-shape/

`POST /v1/mcp` is a Streamable HTTP transport for JSON-RPC 2.0.
Every request is a single JSON-RPC envelope, and the response
comes back over the same HTTP connection. The gateway implements
the [MCP 2024-11-05 spec](https://modelcontextprotocol.io/specification/2024-11-05).

## Required headers

| Header          | Value                                  | Notes                                                                                       |
| --------------- | -------------------------------------- | ------------------------------------------------------------------------------------------- |
| `Authorization` | `Bearer YOUR_API_KEY`                  | Preferred. `x-api-key: YOUR_API_KEY` also works for Anthropic-compatible clients.           |
| `Content-Type`  | `application/json`                     | JSON-RPC body.                                                                              |
| `Accept`        | `application/json, text/event-stream`  | Required by the MCP Streamable HTTP transport. Missing `text/event-stream` returns **406**. |

When both `Authorization` and `x-api-key` are present,
`Authorization: Bearer` takes precedence. A malformed
`Authorization` header is rejected outright — the gateway does
not fall back to `x-api-key`.

`Authorization: Bearer` also accepts a short-lived Cross App Access
token — one an Okta-approved app redeemed on behalf of a signed-in
user, for an organization with
[Cross App Access](/admin/cross-app-access/) enabled. The gateway
tells the two apart by shape, so no separate header or flag is
needed; a static API key remains the default for everything else.

MCP SDKs and the `mcp-remote` bridge set the `Accept` header for
you. Raw `curl` or `httpx` callers must include it explicitly.

## Supported methods

| Method         | Description                                                                              |
| -------------- | ---------------------------------------------------------------------------------------- |
| `initialize`   | Returns server capabilities and identity. Most clients call this once at connection.     |
| `ping`         | No-op heartbeat.                                                                         |
| `tools/list`   | List tools your account is entitled to. See [Scoping](/apis/mcp/scoping/).                       |
| `tools/call`   | Execute a tool on the resolved upstream integration.                                     |

`prompts/*` and `resources/*` methods are not supported. Calls to
them return the protocol's unknown-method error.

## `tools/list` example

```bash
curl -X POST https://api.kindo.ai/v1/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/list",
    "id": 1
  }'
```

Response:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "linear_list_issues",
        "description": "List issues in a Linear team",
        "inputSchema": {
          "type": "object",
          "properties": { "teamId": { "type": "string" } },
          "required": ["teamId"]
        }
      },
      {
        "name": "github_create_issue",
        "description": "Create a GitHub issue",
        "inputSchema": {
          "type": "object",
          "properties": {
            "repo": { "type": "string" },
            "title": { "type": "string" }
          },
          "required": ["repo", "title"]
        }
      }
    ]
  }
}
```

## `tools/call` example

```bash
curl -X POST https://api.kindo.ai/v1/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "id": 2,
    "params": {
      "name": "linear_list_issues",
      "arguments": { "teamId": "TEAM_ID" }
    }
  }'
```

Response:

```json
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [{ "type": "text", "text": "..." }]
  }
}
```

## Tool naming convention

Tool names are prefixed with their integration identifier to
avoid collisions across providers. The format is:

```text
{server}_{name}
```

For example:

- `linear_list_issues` — the `list_issues` tool from the Linear
  integration.
- `github_create_issue` — the `create_issue` tool from the GitHub
  integration.
- `slack_post_message` — the `post_message` tool from the Slack
  integration.

The gateway splits on the **first underscore only**. Kindo's
integration IDs use hyphens (e.g., `sap-s4hana-rfc`), so names
like `sap-s4hana-rfc_invoke_bapi` resolve cleanly to server
`sap-s4hana-rfc` and tool `invoke_bapi`. You only need to know the
integration ID to address its tools.

## See also

- [Quickstart](/apis/mcp/quickstart/) — the smallest working call.
- [Scoping](/apis/mcp/scoping/) — what `tools/list` returns and how to
  narrow it.
- [Errors](/apis/mcp/errors/) — HTTP and protocol error envelopes.

---

## Messages API streaming

Source: https://docs.kindo.ai/apis/messages/streaming/

Set `"stream": true` on `POST /v1/messages` to receive a standard
Anthropic Server-Sent Events stream. Existing Anthropic SDK
consumers work unchanged.

## Request

```bash
curl -N https://api.kindo.ai/v1/messages \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-4-5-20250929",
    "max_tokens": 512,
    "stream": true,
    "messages": [
      { "role": "user", "content": "Write a haiku about observability." }
    ]
  }'
```

Kindo returns `Content-Type: text/event-stream` and emits
Anthropic's event sequence verbatim.

## Event types

| Event                 | Meaning                                           |
| --------------------- | ------------------------------------------------- |
| `message_start`       | Initial message metadata.                         |
| `content_block_start` | Start of a streamed content block.                |
| `content_block_delta` | Incremental content chunk.                        |
| `content_block_stop`  | End of a content block.                           |
| `message_delta`       | Updated usage or stop-reason data.                |
| `message_stop`        | End of the stream.                                |
| `error`               | Stream interruption after the stream has started. |
| `ping`                | Keepalive heartbeat; safe to ignore.              |

## Example stream

```
event: message_start
data: {"type":"message_start","message":{"id":"msg_01","type":"message","role":"assistant","content":[],"model":"claude-sonnet-4-5-20250929","stop_reason":null,"usage":{"input_tokens":12,"output_tokens":1}}}

event: content_block_start
data: {"type":"content_block_start","index":0,"content_block":{"type":"text","text":""}}

event: content_block_delta
data: {"type":"content_block_delta","index":0,"delta":{"type":"text_delta","text":"Logs flow through"}}

event: content_block_delta
data: {"type":"content_block_delta","index":0,"delta":{"type":"text_delta","text":" the gate;"}}

event: content_block_stop
data: {"type":"content_block_stop","index":0}

event: message_delta
data: {"type":"message_delta","delta":{"stop_reason":"end_turn"},"usage":{"output_tokens":32}}

event: message_stop
data: {"type":"message_stop"}
```

## SDK consumption

```python

from anthropic import Anthropic

client = Anthropic(base_url="https://api.kindo.ai", api_key=os.environ["KINDO_API_KEY"])

with client.messages.stream(
    model="claude-sonnet-4-5-20250929",
    max_tokens=512,
    messages=[{"role": "user", "content": "Write a haiku."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)
```

```ts

const client = new Anthropic({
  baseURL: 'https://api.kindo.ai',
  apiKey: process.env.KINDO_API_KEY
});

const stream = await client.messages.stream({
  model: 'claude-sonnet-4-5-20250929',
  max_tokens: 512,
  messages: [{ role: 'user', content: 'Write a haiku.' }]
});

for await (const event of stream) {
  if (
    event.type === 'content_block_delta' &&
    event.delta.type === 'text_delta'
  ) {
    process.stdout.write(event.delta.text);
  }
}
```

## Pre-stream errors

If the upstream request fails before streaming begins, Kindo returns
a normal HTTP error response with Anthropic's JSON envelope — no
SSE switch. See [Errors](/apis/messages/errors/).

## Mid-stream errors

Once the SSE has started, the outer HTTP status is committed at
`200`. Stream errors arrive as an `event: error` SSE frame
**in place of `message_stop`**:

```
event: error
data: {"type":"error","error":{"type":"overloaded_error","message":"upstream overloaded"}}
```

Treat any `error` SSE event as terminal — no `message_stop`
follows and the response will not resume.

## See also

- [Quickstart](/apis/messages/quickstart/) — non-streaming round trip.
- [Request shape](/apis/messages/request-shape/) — every field Kindo honors.
- [Tool use](/apis/messages/tool-use/) — streaming tool-call events.
- [Errors](/apis/messages/errors/) — pre-stream error envelopes.

---

## Responses API streaming

Source: https://docs.kindo.ai/apis/responses/streaming/

Set `"stream": true` on `POST /v1/responses` to receive Server-Sent
Events. Kindo emits the standard OpenAI Responses stream — your
existing parser works without changes.

## Request

```bash
curl -N https://api.kindo.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "model": "claude-sonnet-4-5-20250929",
    "stream": true,
    "input": "Write a haiku about observability."
  }'
```

`stream` is consumed by the Kindo route handler to flip the response
into `Content-Type: text/event-stream` mode. It is not forwarded as
a model parameter.

## Event types

Each event has a named `event:` line and a JSON `data:` payload. The
event names match OpenAI's Responses streaming spec:

| Event                                    | Meaning                                                     |
| ---------------------------------------- | ----------------------------------------------------------- |
| `response.created`                       | Initial response object is allocated.                       |
| `response.in_progress`                   | Generation has started.                                     |
| `response.output_item.added`             | A new output item (message, function call, etc.) has begun. |
| `response.output_item.done`              | An output item has completed.                               |
| `response.content_part.added`            | A new content part within a message has begun.              |
| `response.content_part.done`             | A content part has completed.                               |
| `response.output_text.delta`             | Incremental text chunk for an `output_text` content part.   |
| `response.output_text.done`              | The full text for a content part is now stable.             |
| `response.function_call_arguments.delta` | Incremental JSON for a function-call's `arguments`.         |
| `response.function_call_arguments.done`  | Function-call arguments are complete.                       |
| `response.completed`                     | The whole response is finished.                             |
| `response.failed`                        | The response terminated in an error state.                  |
| `error`                                  | Mid-stream error. See "Mid-stream errors" below.            |

When the response produces reasoning or server-side tool activity
(Kindo-hosted tools, MCP tools, agent runs), the same protocol carries
those items too:

| Event                                                                    | Meaning                                                     |
| ------------------------------------------------------------------------ | ----------------------------------------------------------- |
| `response.reasoning_summary_part.added` / `.done`                        | A reasoning summary part within a `reasoning` item.         |
| `response.reasoning_summary_text.delta` / `.done`                        | Incremental reasoning-summary text.                         |
| `response.mcp_call_arguments.delta` / `.done`                            | Incremental JSON for an `mcp_call` item's `arguments`.      |
| `response.kindo_call_arguments.delta` / `.done`                          | Incremental JSON for a `kindo_call` item's `arguments`.     |

The corresponding output items (`reasoning`, `mcp_call`, `kindo_call`,
`shell_call`, `web_search_call`) open and close with the same
`response.output_item.added` / `response.output_item.done` pairs as
messages and function calls. Agent-run invocations
(`model: "agent/<agent-id>"`) stream this full vocabulary live as the
run executes — see
[Invoke Kindo agents](/guides/invoke-agents-responses-api/#stream-the-run-live).

## Example stream

```
event: response.created
data: {"id":"resp_abc123","status":"in_progress","object":"response"}

event: response.output_text.delta
data: {"item_id":"msg_xyz","delta":"Logs flow through"}

event: response.output_text.delta
data: {"item_id":"msg_xyz","delta":" the gate;\nMetrics rise like steam"}

event: response.output_text.done
data: {"item_id":"msg_xyz","text":"Logs flow through the gate;\nMetrics rise like steam,\ntraces find their way."}

event: response.completed
data: {"id":"resp_abc123","status":"completed","object":"response"}
```

## SDK consumption

Standard OpenAI SDK `stream=True` works as expected:

```python

from openai import OpenAI

client = OpenAI(base_url="https://api.kindo.ai/v1", api_key=os.environ["KINDO_API_KEY"])

stream = client.responses.create(
    model="claude-sonnet-4-5-20250929",
    input="Write a haiku about observability.",
    stream=True,
)

for event in stream:
    if event.type == "response.output_text.delta":
        print(event.delta, end="", flush=True)
```

```ts

const client = new OpenAI({
  baseURL: 'https://api.kindo.ai/v1',
  apiKey: process.env.KINDO_API_KEY
});

const stream = await client.responses.create({
  model: 'claude-sonnet-4-5-20250929',
  input: 'Write a haiku about observability.',
  stream: true
});

for await (const event of stream) {
  if (event.type === 'response.output_text.delta') {
    process.stdout.write(event.delta);
  }
}
```

## Pre-stream errors

If the upstream request fails before streaming begins (for example,
auth fails, the model isn't found, the body is invalid), Kindo
returns a normal HTTP error response with a JSON envelope — no
SSE switch. See [Errors](/apis/responses/errors/) for shapes.

## Mid-stream errors

Once the first SSE byte has been written, the outer HTTP status is
already committed at `200`. Errors that arise after that point arrive
as an `error` event followed by the appropriate terminal event:

```
event: error
data: {"error":{"message":"upstream stream interrupted","type":"server_error","code":"stream_error"}}

event: response.failed
data: {"id":"resp_abc123","status":"failed","object":"response"}
```

Treat any `error` SSE event as terminal — the response will not
resume.

## Resuming a dropped stream

If the SSE connection drops mid-stream (a flaky network, a proxy
timeout), you can reconnect to the **same** response and replay the
events you missed instead of issuing a new `POST` — which would start a
new response. Every streamed event carries its `sequence_number` both in
the `data:` payload and as the SSE `id:` line:

```
id: 4
event: response.output_text.delta
data: {"item_id":"msg_xyz","delta":" the gate","sequence_number":4}
```

Reconnect with `GET` on the response id, passing `stream=true` and the
last `sequence_number` you received as `starting_after`:

```bash
curl -N "https://api.kindo.ai/v1/responses/resp_abc123?stream=true&starting_after=4" \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

Kindo replays every event **after** `sequence_number` 4 with continuous
numbering, then continues live until the response completes (or emits
`response.completed` immediately if it already finished). No new response
is created. Omit `starting_after` to replay from the beginning. A negative
or non-integer `starting_after` returns HTTP 400.

Browser `EventSource` clients resume automatically: the runtime resends
the last `id:` it saw as the `Last-Event-ID` request header, which Kindo
honors when `starting_after` is absent.

The resume window is **time-bounded** (the same window over which a
response is retained for polling). After it elapses, a streamed resume
falls back to the response's final items followed by `response.completed`
— the per-token deltas are no longer available. Retrieve the final object
with a plain `GET` (no `stream`) instead.

### Agent-run responses replay from the start only

Responses backed by an agent run (ids of the form `resp_run_<runId>`)
support **full replay only** — not incremental resume. Reconnect with
`stream=true` and `starting_after=0` (or omit `starting_after`) to replay
the run's events from the beginning and continue live:

```bash
curl -N "https://api.kindo.ai/v1/responses/resp_run_abc123?stream=true&starting_after=0" \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

A **positive** `starting_after` on a `resp_run_*` id returns HTTP 400. An
agent run streams many steps, and a step that is still live emits per-token
deltas while a step already finished replays only its completed items, so the
event numbering is not stable enough to splice a partial reconnect onto
reliably. Replaying from the start avoids any gap or duplication.

## See also

- [Quickstart](/apis/responses/quickstart/) — non-streaming round trip.
- [Request shape](/apis/responses/request-shape/) — every field Kindo honors.
- [Tool use](/apis/responses/tool-use/) — streaming tool-call events.
- [Errors](/apis/responses/errors/) — pre-stream error envelopes.

---

## Model catalog

Source: https://docs.kindo.ai/overview/model-catalog/

The same model registry backs every inference API on `api.kindo.ai`.
Whichever model ID you discover via `/v1/models` works as the `model`
parameter on `/v1/chat/completions`, `/v1/responses`, and
`/v1/messages` — Kindo routes to the correct upstream provider for
you.

## Discover available models

```bash
curl https://api.kindo.ai/v1/models \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

The response uses the standard OpenAI models-list format, enriched
with the human-readable `display_name`:

```json
{
  "object": "list",
  "data": [
    {
      "id": "claude-sonnet-4-5-20250929",
      "object": "model",
      "created": 0,
      "owned_by": "kindo",
      "display_name": "Claude Sonnet 4.5"
    },
    {
      "id": "gpt-4o-2024-11-20",
      "object": "model",
      "created": 0,
      "owned_by": "kindo",
      "display_name": "GPT-4o"
    }
  ]
}
```

You only see models your organization has access to — model
visibility is governed by your user-group configuration.

### Model display name

Beyond the four OpenAI fields (`id`, `object`, `created`,
`owned_by`), each proxied-model entry carries one additive Kindo
field:

| Field          | Type   | Description                                                |
| -------------- | ------ | ---------------------------------------------------------- |
| `display_name` | string | Human-readable model name, as shown in the Kindo Terminal. |

This field is **additive** — `id` is still the model ID you pass back
as the `model` parameter, and OpenAI SDK clients ignore the extra
field, so existing integrations are unaffected. Agent entries
(`include_agents=true`, below) do not carry it.

You can also inspect the same list under
[**Settings** > **Kindo API** > **Available Models**](https://app.kindo.ai/?settings=api/available-models)
in the Kindo Terminal.

## Listing agents as models

Your stored Kindo agents are invocable as models on `/v1/responses`
(see [Invoke Kindo agents with the Responses API](/guides/invoke-agents-responses-api/)).
Add `include_agents=true` to list them alongside the model catalog:

```bash
curl "https://api.kindo.ai/v1/models?include_agents=true" \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

Agent entries use the same models-list shape:

```json
{
  "id": "agent/8e051857-978c-4207-8916-28a3d4c4d605",
  "object": "model",
  "created": 1748736000,
  "owned_by": "Acme Inc"
}
```

- `id` is `agent/<agent-id>` — pass it directly as the `model`
  parameter on `POST /v1/responses`.
- `owned_by` is your organization's name (or its ID when the org has
  no display name), distinguishing agents from `"kindo"`-owned models.
- `created` is the agent's actual creation timestamp.
- Only agents you can access are listed, scoped the same way as
  [`GET /v1/agents/list`](/apis/agents/quickstart/). Agents with
  triggers (scheduled, event, or webhook) are included — a trigger is
  an additional way the agent starts and does not prevent invoking it
  directly.

The agents portion is paginated. Pass `limit` (1–1000, default 500)
and `after` (an offset, default 0) to page through them; the response
carries `has_more` and a `next_after` offset to request the next page:

```bash
# First page
curl "https://api.kindo.ai/v1/models?include_agents=true&limit=2" \
  -H "Authorization: Bearer $KINDO_API_KEY"
# → "has_more": true, "next_after": 2

# Next page
curl "https://api.kindo.ai/v1/models?include_agents=true&limit=2&after=2" \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

Repeat with `after = next_after` until `has_more` is `false` to walk
the complete set. Proxied (`"kindo"`-owned) models are not paginated —
they are returned in full on the first page (`after=0`) only and omitted
from later pages, so concatenating pages yields exactly one copy of each.

Offsets are stable as long as the agent set is unchanged between page
requests; an agent created or deleted mid-walk shifts the window and can
skip or duplicate an entry across page boundaries (inherent to offset
pagination).

Without the parameter (the default), the response is unchanged except
for an added `"has_more": false` — existing `/v1/models` consumers are
unaffected. Agent IDs are only valid on `/v1/responses`; the other
inference endpoints treat them as an unknown model.

## Naming conventions

Model IDs follow the upstream provider's published name with the
date suffix the provider uses. A few representative examples:

| Family           | Example IDs                                            |
| ---------------- | ------------------------------------------------------ |
| Anthropic Claude | `claude-sonnet-4-5-20250929`, `claude-opus-4-20251125` |
| OpenAI GPT       | `gpt-4o-2024-11-20`, `gpt-4o-mini-2024-07-18`          |
| OpenAI o-series  | `o1-2024-12-17`, `o3-mini-2025-01-31`                  |

Kindo does not rename models. If you've used these IDs against the
upstream provider directly, the same string works against
`api.kindo.ai`.

The exact set evolves — `GET /v1/models` is the source of truth.
Hard-coding a model ID into your client is fine; assuming a model
will exist forever is not. Inference endpoints return `400` for an
unknown model.

## Cross-API model use

You can use the same model ID on whichever inference protocol your
client speaks:

- A `claude-*` model works on `/v1/chat/completions`,
  `/v1/responses`, and `/v1/messages` — Kindo translates the wire
  format for you.
- A `gpt-*` model works on all of them — same translation.

In practice, pick the protocol that matches your SDK; pick the
model based on capability, latency, and cost.

## Errors

| Status                      | Meaning                                                                                                                                                                                                                                                        |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `403` `model_access_denied` | The model exists but your organization is not entitled to call it.                                                                                                                                                                                             |
| `400` `model_not_found`     | The model ID is not registered on inference endpoints. Check `GET /v1/models`. Emitted by `/v1/chat/completions` and `/v1/responses`. `/v1/messages` returns `400 invalid_request_error` without a code field — see [Messages errors](/apis/messages/errors/). |

If your client returns a model error, hit `/v1/models` first. Most
"unknown model" reports trace back to a stale model ID.

## See also

- [Authentication](/overview/authentication/) — get a key and call
  `/v1/models`.
- [Responses API quickstart](/apis/responses/quickstart/) /
  [Chat Completions quickstart](/apis/chat-completions/quickstart/) /
  [Messages quickstart](/apis/messages/quickstart/) — use a model ID
  on each surface.

---

## Agents API errors

Source: https://docs.kindo.ai/apis/agents/errors/

The Agents endpoints return errors using a **flat** envelope: a short
`error` label plus a `message` field with the specific cause. This
differs from the OpenAI-compatible nested envelope used by
`/v1/responses` and `/v1/conversations/*`.

## Envelope

```json
{
  "error": "Not found",
  "message": "Agent 18d20df4-d9b3-4cb0-a009-9f11ec9c5d3d not found."
}
```

## Status reference

| Status | `error`                  | Cause                                                                                                                                                                                                                                                            |
| ------ | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `400`  | `Bad Request`            | Malformed request body — e.g. missing `agentId` on `POST /v1/agents/runs`, or a body that fails Zod schema validation.                                                                                                                                            |
| `401`  | `Unauthorized`           | Missing, malformed, or revoked API key. Emitted by the auth middleware; the body is `{"error": "Unauthorized", "message": "..."}`.                                                                                                                                |
| `404`  | `Not found`              | `agentId` does not exist or is not visible to the caller; `runId` does not exist or the caller cannot read the underlying conversation. Per-agent permission denials also collapse to `404` — Kindo does not distinguish "missing" from "forbidden" on this surface. |
| `413`  | —                        | JSON request body exceeds the 50 MB (52,428,800-byte) limit. This check runs before the endpoint and returns `{"message":"Request body too large. Maximum size is 50 MB."}`.                      |
| `422`  | `Unprocessable Entity`   | Body parsed, but the request cannot be executed — required `inputs[].name` entries declared by the agent are missing from the request.                                                              |
| `429`  | `Too Many Requests`      | Org or user rate limit. Honors `Retry-After` when present.                                                                                                                                                                                                       |
| `500`  | `Internal Server Error`  | Unexpected Kindo-side failure.                                                                                                                                                                                                                                   |

Unknown `inputs[].name` entries on `POST /v1/agents/runs` are
**silently dropped** rather than rejected — only the missing-required
case produces a `422`. Re-fetch `GET /v1/agents/{agentId}` to confirm
the canonical label list if a run isn't picking up the values you
expected.

## Common causes by endpoint

### `POST /v1/agents/runs`

A `422 Unprocessable Entity` here means the request omitted a
required `inputs[].name` declared on the agent. The labels are
case-sensitive and must match exactly. Fetch
`GET /v1/agents/{agentId}` to confirm the canonical list before
retrying. (Triggers do not block this endpoint — an agent with
`hasTriggers: true` can still be run directly.)

A `404 Not found` here means the `agentId` is unknown to the caller —
either it does not exist, or the user group does not grant access.
Permission failures intentionally collapse to `404` and are not
distinguished from "missing" in the response.

### `GET /v1/runs/{runId}`

A `404 Not found` here means either the `runId` is bogus, the
caller cannot read the underlying conversation, or the run has been
pruned by retention. The three cases are not distinguished in the
response envelope.

A run that finished with `status: "failure"` is **not** an HTTP error
— it returns `200` with a status payload. Inspect the `status` field,
not the HTTP code, to detect agent-level failures.

### `POST /v1/runs/{runId}/restart`

A `404 Not found` means the run does not exist or the caller lacks
access — the same collapse-to-`404` behavior as `GET /v1/runs/{runId}`.
The two cases are intentionally indistinguishable.

A `400 Bad Request` indicates a malformed `runId` (not a valid UUID).

### `GET /v1/runs/{runId}/evals`

Error behavior mirrors `GET /v1/runs/{runId}` — a `404 Not found`
means the run does not exist or the caller lacks access. The two cases
are intentionally indistinguishable.

A `400 Bad Request` indicates a malformed `runId` (not a valid UUID).

## See also

- [Authentication](/overview/authentication/) — `401` causes.
- [Quickstart](/apis/agents/quickstart/) — input-label discovery flow that
  prevents `422` errors.

---

## Chat Completions API tool use

Source: https://docs.kindo.ai/apis/chat-completions/tool-use/

`POST /v1/chat/completions` accepts OpenAI's standard function-tool
shape. Definitions and `tool_choice` flow through verbatim — no
Kindo-specific wrapping.

## Define a function tool

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "messages": [
    { "role": "user", "content": "What is the weather in San Francisco?" }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Get the current weather for a city.",
        "parameters": {
          "type": "object",
          "properties": {
            "location": { "type": "string" }
          },
          "required": ["location"]
        }
      }
    }
  ],
  "tool_choice": "auto"
}
```

Note the nested `function` object — that's the Chat Completions tool
shape (different from the Responses API, where `name` /
`description` / `parameters` sit at the top level of the tool entry).

## Round trip

### Step 1 — initial request

Submit the request above.

### Step 2 — assistant message with `tool_calls`

```json
{
  "id": "chatcmpl-abc123",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": null,
        "tool_calls": [
          {
            "id": "call_abc",
            "type": "function",
            "function": {
              "name": "get_weather",
              "arguments": "{\"location\":\"San Francisco, CA\"}"
            }
          }
        ]
      },
      "finish_reason": "tool_calls"
    }
  ]
}
```

`finish_reason: "tool_calls"` is the canonical signal that the model
wants you to execute a tool.

### Step 3 — execute the tool client-side

Run `get_weather("San Francisco, CA")` in your application.

### Step 4 — submit the result

Send a follow-up request with the assistant message preserved and a
new `tool` message carrying the result:

```bash
curl -X POST https://api.kindo.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "model": "claude-sonnet-4-5-20250929",
    "messages": [
      { "role": "user", "content": "What is the weather in San Francisco?" },
      {
        "role": "assistant",
        "content": null,
        "tool_calls": [
          {
            "id": "call_abc",
            "type": "function",
            "function": {
              "name": "get_weather",
              "arguments": "{\"location\":\"San Francisco, CA\"}"
            }
          }
        ]
      },
      {
        "role": "tool",
        "tool_call_id": "call_abc",
        "content": "{\"temperature\":68,\"unit\":\"fahrenheit\"}"
      }
    ],
    "tools": [
      {
        "type": "function",
        "function": {
          "name": "get_weather",
          "description": "Get the current weather for a city.",
          "parameters": {
            "type": "object",
            "properties": { "location": { "type": "string" } },
            "required": ["location"]
          }
        }
      }
    ]
  }'
```

The `tool_call_id` must match the one from Step 2. Re-include
`tools` so the model still sees the schema.

### Step 5 — final answer

```json
{
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "It's 68 °F in San Francisco."
      },
      "finish_reason": "stop"
    }
  ]
}
```

## `tool_choice`

| Value                                         | Behavior                                             |
| --------------------------------------------- | ---------------------------------------------------- |
| `"auto"` (default)                            | The model decides whether to call a tool.            |
| `"none"`                                      | The model must produce a message; never a tool call. |
| `"required"`                                  | The model must call at least one tool.               |
| `{type: "function", function: {name: "..."}}` | The model must call exactly that function.           |

## See also

- [Request shape](/apis/chat-completions/request-shape/) — full field reference.
- [Streaming](/apis/chat-completions/streaming/) — `delta.tool_calls` events.
- [Errors](/apis/chat-completions/errors/) — error envelopes for tool-call failures and provider passthrough.

---

## MCP API scoping

Source: https://docs.kindo.ai/apis/mcp/scoping/

When you call `tools/list`, the gateway builds the list from your authorized
integration connections and available first-party Platform tools, then applies
your organization's server and tool permissions. Platform tools do not require
an integration connection. Discovery does not grant access to every resource
a tool can act on; each call checks access to the requested resource.

## What you see in `tools/list`

A tool needs **at least one** of these access paths to appear:

1. **You personally have a connection** to that integration —
   e.g., you connected your own Linear or GitHub account in Kindo.
2. **Someone in your org has shared a connection** with you — a
   teammate's connection that your account is allowed to use.
3. **The integration is public** — no credentials required, like
   the built-in `browser` integration.
4. **It is an available first-party Platform tool** — Platform MCP must be
   configured, and the tool must meet its discovery requirements. Directory
   and department tools are omitted unless you meet their
   [role and department-access requirements](/reference/tool-catalog/#platform-tools).
   These tools do not use an integration connection.

If none of these is true for a given integration, none of its
tools appear in `tools/list`, and a direct `tools/call` on one of
those tools returns the protocol's invalid-params error.

The tool must also pass your organization's server and tool permissions.
The [organization's approval setting](/admin/rbac-tool-actions/#organization-approval-setting)
applies to external MCP: **Run automatically**
permits otherwise-authorized tools, while **Ask before running** and **Block**
omit them from `tools/list` and prevent execution.

Your personal tool approval settings apply to Kindo chats and agents. They do
not restrict external MCP access or override organization restrictions. Configure
which permitted tools to use and when to request approval in your external client.

Every `tools/call` checks the current organization settings again, including calls
using a previously discovered tool name. Platform directory and department calls
also recheck their role and department-access requirements, so a tool discovered
before access was revoked cannot bypass those checks. An organization requirement for manual
approval returns
[`manual_approval_required`](/apis/mcp/errors/#manual_approval_required-envelope);
use Kindo chat if manual approvals are enabled for your organization, or contact
your administrator. An organization **Block** setting returns the invalid-params
error (`-32602`).

You don't need to pass any filter or flag to get this behavior.
The bare `POST /v1/mcp` endpoint returns the right list for your
account by default.

## Narrowing the list

For agents that only need a subset of your tools — for example, a
Linear-only agent — the gateway accepts an allow-list as
**either** a query parameter or a header:

```bash
# Query parameter
curl -X POST "https://api.kindo.ai/v1/mcp?integrations=linear,github" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/list",
    "id": 1
  }'

# Header (equivalent)
curl -X POST https://api.kindo.ai/v1/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -H "x-kindo-integrations: linear,github" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/list",
    "id": 1
  }'
```

The filter narrows the set you would otherwise see — it never
grants access. If your account doesn't have a path to GitHub and
you pass `?integrations=linear,github`, you get only Linear tools
back (no error). Names in the filter must match the integration ID
exactly (e.g., `linear`, `github`, `platform`, `sap-s4hana-rfc`).

Both forms accept comma-separated values. The query parameter
also accepts array repetition (`?integrations=linear&integrations=github`).
If both query and header are present, the query parameter wins.
A missing or empty filter value is ignored.

### Why narrow?

The bare list includes eligible tools across the integrations your API key can reach.
For accounts with broad shared connections that can be 1000+
tools — enough to exceed most chat clients' context windows. A
narrow filter keeps the tool surface small:

- **Context-budget reasons.** Many MCP clients send the full tool
  catalog to the model on every turn. Fewer tools means a smaller
  system prompt and more room for actual work.
- **Per-agent focus.** Pin a single MCP client to one or two
  integrations even though your API key has access to more.
- **Stable surface.** Decouple your client from new integrations
  added to your org later.

## Default-connection resolution

When your account has more than one connection for the same
integration — say, two Linear accounts — the gateway has to pick
one for every `tools/call` to that connected integration. First-party
Platform tools do not use a connection or a default. The resolution chain
for connected integrations is:

1. **Only one connection.** Use it.
2. **You selected active connections.** Kindo uses the first usable connection
   in your active set. You can also replace that set with one preferred
   connection via `POST /v1/integrations/connections/{integration_id}/default`
   (see [Kindo extensions](/apis/mcp/kindo-extensions/)).
3. **You own at least one connection.** Use your most recently
   created owned connection.
4. **You don't own any, but a shared one is available.** Use the
   most recently created shared connection.

If the chosen connection's credentials have been revoked or
expired, the call returns a `credentials_unavailable` error with
a hint to reconnect. See [Errors](/apis/mcp/errors/) for the exact
envelope.

Kindo chats and agents can choose an account for each tool call from your
active connections or their pinned connections. External MCP clients use
one connection per integration, selected by the resolution chain above;
their tools do not expose a per-call account selector. Platform tools remain
connectionless.

## See also

- [Quickstart](/apis/mcp/quickstart/) — first call.
- [Request shape](/apis/mcp/request-shape/) — supported methods and
  headers.
- [Kindo extensions](/apis/mcp/kindo-extensions/) — the connection-
  management REST endpoints used by step 2.

---

## Messages API tool use

Source: https://docs.kindo.ai/apis/messages/tool-use/

`POST /v1/messages` accepts Anthropic's standard tool definitions.
`tool_use` and `tool_result` content blocks pass through to the
upstream provider with no Kindo-specific wrapping.

## Define a function tool

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "max_tokens": 512,
  "tools": [
    {
      "name": "get_weather",
      "description": "Get the current weather for a city.",
      "input_schema": {
        "type": "object",
        "properties": {
          "location": { "type": "string" }
        },
        "required": ["location"]
      }
    }
  ],
  "messages": [
    { "role": "user", "content": "What is the weather in San Francisco?" }
  ]
}
```

Anthropic tool definitions use `name` / `description` /
`input_schema` (different from Chat Completions' nested `function`
object).

## Round trip

### Step 1 — initial request

Submit the request above.

### Step 2 — assistant message with `tool_use`

```json
{
  "id": "msg_01",
  "role": "assistant",
  "content": [
    {
      "type": "tool_use",
      "id": "toolu_01",
      "name": "get_weather",
      "input": { "location": "San Francisco, CA" }
    }
  ],
  "stop_reason": "tool_use"
}
```

`stop_reason: "tool_use"` is the canonical signal that the model
wants you to run a tool.

### Step 3 — execute the tool client-side

Run `get_weather({ location: "San Francisco, CA" })` in your
application.

### Step 4 — submit the result

Return the result as a `tool_result` content block in a `user`
message. Re-include the prior assistant message and re-include
`tools` so the model has the schema:

```bash
curl -X POST https://api.kindo.ai/v1/messages \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-4-5-20250929",
    "max_tokens": 512,
    "tools": [
      {
        "name": "get_weather",
        "description": "Get the current weather for a city.",
        "input_schema": {
          "type": "object",
          "properties": { "location": { "type": "string" } },
          "required": ["location"]
        }
      }
    ],
    "messages": [
      { "role": "user", "content": "What is the weather in San Francisco?" },
      {
        "role": "assistant",
        "content": [
          {
            "type": "tool_use",
            "id": "toolu_01",
            "name": "get_weather",
            "input": { "location": "San Francisco, CA" }
          }
        ]
      },
      {
        "role": "user",
        "content": [
          {
            "type": "tool_result",
            "tool_use_id": "toolu_01",
            "content": "{\"temperature\":68,\"unit\":\"fahrenheit\"}"
          }
        ]
      }
    ]
  }'
```

The `tool_use_id` on the `tool_result` block must match the `id`
on the originating `tool_use` block.

### Step 5 — final answer

```json
{
  "id": "msg_02",
  "role": "assistant",
  "content": [{ "type": "text", "text": "It's 68 °F in San Francisco." }],
  "stop_reason": "end_turn"
}
```

## `tool_choice`

Anthropic's tool-choice format:

| Value                               | Behavior                                  |
| ----------------------------------- | ----------------------------------------- |
| `{ "type": "auto" }` (default)      | The model decides whether to call a tool. |
| `{ "type": "any" }`                 | The model must call at least one tool.    |
| `{ "type": "tool", "name": "..." }` | The model must call exactly that tool.    |

## See also

- [Request shape](/apis/messages/request-shape/) — full field reference.
- [Streaming](/apis/messages/streaming/) — `tool_use` content-block streaming.
- [Errors](/apis/messages/errors/) — error envelopes for tool-call failures and provider passthrough.

---

## Responses API tool use

Source: https://docs.kindo.ai/apis/responses/tool-use/

The Responses API uses OpenAI's typed-output tool-call shape. The
flow is:

1. You send a request with `tools` defined.
2. The model decides to call a tool. The response status is
   `incomplete` and `output` contains a `function_call` item.
3. You execute the tool client-side and send the result back as a
   `function_call_output` input item, referencing the same `call_id`.
4. The model continues with the result and emits a final
   `message`.

## Define a function tool

Function tools are defined in the Responses-API tool format
(top-level `name`, `description`, `parameters`):

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "input": "What is the weather in San Francisco?",
  "tools": [
    {
      "type": "function",
      "name": "get_weather",
      "description": "Get the current weather for a city.",
      "parameters": {
        "type": "object",
        "properties": {
          "location": { "type": "string" }
        },
        "required": ["location"]
      }
    }
  ],
  "tool_choice": "auto"
}
```

This is the shape `codex` and `openai-python`'s `client.responses`
produce.

## Round trip

> Set `store: true` to persist the response server-side. The response
> includes `conversation.id` when `store: true`, which you can use for
> stateful continuation, or ignore it for a one-shot call.

### Step 1 — initial request

```bash
curl -X POST https://api.kindo.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "model": "claude-sonnet-4-5-20250929",
    "store": true,
    "input": "What is the weather in San Francisco?",
    "tools": [
      {
        "type": "function",
        "name": "get_weather",
        "description": "Get the current weather for a city.",
        "parameters": {
          "type": "object",
          "properties": { "location": { "type": "string" } },
          "required": ["location"]
        }
      }
    ]
  }'
```

### Step 2 — tool-call response

```json
{
  "id": "resp_abc123",
  "status": "incomplete",
  "incomplete_details": { "reason": "tool_use" },
  "conversation": { "id": "conv_abc123" },
  "output": [
    {
      "type": "function_call",
      "call_id": "call_abc",
      "name": "get_weather",
      "arguments": "{\"location\":\"San Francisco, CA\"}"
    }
  ]
}
```

`status: "incomplete"` with `incomplete_details.reason: "tool_use"`
is the canonical signal that the model wants you to run a tool.

> **Kindo divergence from OpenAI spec:** OpenAI's published Responses API
> uses `status: "completed"` with a `function_call` output item when the
> model calls a tool. Kindo returns `status: "incomplete"` with
> `incomplete_details.reason: "tool_use"` instead. Stock OpenAI SDKs
> will see this divergence when consuming raw HTTP responses.

### Step 3 — execute the tool client-side

Run `get_weather("San Francisco, CA")` in your application. This is
your code, not Kindo's — function tools are by definition
client-executed.

### Step 4 — submit the result

```bash
curl -X POST https://api.kindo.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{
    "model": "claude-sonnet-4-5-20250929",
    "conversation": "conv_abc123",
    "input": [
      { "type": "message", "role": "user", "content": "What is the weather in San Francisco?" },
      {
        "type": "function_call",
        "call_id": "call_abc",
        "name": "get_weather",
        "arguments": "{\"location\":\"San Francisco, CA\"}"
      },
      {
        "type": "function_call_output",
        "call_id": "call_abc",
        "output": "{\"temperature\":68,\"unit\":\"fahrenheit\"}"
      }
    ],
    "tools": [
      {
        "type": "function",
        "name": "get_weather",
        "description": "Get the current weather for a city.",
        "parameters": {
          "type": "object",
          "properties": { "location": { "type": "string" } },
          "required": ["location"]
        }
      }
    ]
  }'
```

The `call_id` must match the one from Step 2. Re-include the `tools`
definition so the model sees the schema again. Re-include the prior
input messages so the model has the context of the tool call.
Alternatively, continue statefully — pass `conversation` or chain via
`previous_response_id` (the prior turns are then loaded server-side).
See [Chat Actions extensions](/apis/responses/kindo-extensions/) for the stateful
continuation recipe.

### Step 5 — final answer

```json
{
  "id": "resp_def456",
  "status": "completed",
  "output": [
    {
      "type": "message",
      "role": "assistant",
      "content": [
        { "type": "output_text", "text": "It's 68 °F in San Francisco." }
      ]
    }
  ],
  "output_text": "It's 68 °F in San Francisco."
}
```

## `tool_choice`

| Value                                                 | Behavior                                                                                             |
| ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| `"auto"` (default)                                    | The model decides whether to call a tool.                                                            |
| `"none"`                                              | The model must produce a message; never a tool call.                                                 |
| `"required"`                                          | The model must call at least one tool.                                                              |
| `{type: "function", name: "..."}`                     | The model must call exactly that function.                                                           |
| `{type: "allowed_tools", mode: "auto", tools: [...]}` | Restricts the model to a subset of declared tools. Works for `function`, `mcp`, and `kindo_*` tools. |

## Other tool types

`POST /v1/responses` also accepts:

- `{type: "mcp", server_label: "<your-mcp-server>"}` — MCP tools
  registered against your organization. **Stateful path only**: the
  `server_label` is resolved server-side against your organization's
  integrations, so the request must set `store: true` or pass a
  `conversation` ID. A stateless request that includes an `mcp` tool
  is rejected with `400 unsupported_tool_type`.
- `{type: "kindo_<name>"}` — individual Kindo-hosted tools (opt-in).
- `{type: "kindo_tools"}` — sugar that expands to the full Kindo
  hosted-tool catalog.

Stock OpenAI built-in types (`web_search`, `file_search`, `computer`,
`shell`, etc.) are forwarded verbatim and dispatched to the upstream
model when supported.

See [Chat Actions extensions](/apis/responses/kindo-extensions/) for the full
hosted-tool catalog and stateful flow patterns.

## See also

- [Request shape](/apis/responses/request-shape/) — full field reference.
- [Streaming](/apis/responses/streaming/) — `function_call_arguments.delta` events.
- [Chat Actions extensions](/apis/responses/kindo-extensions/) — Kindo-hosted
  tools.
- [Errors](/apis/responses/errors/) — error envelopes for tool-call failures and provider passthrough.

---

## Chat Completions API errors

Source: https://docs.kindo.ai/apis/chat-completions/errors/

`POST /v1/chat/completions` returns errors in OpenAI's Chat
Completions error envelope. Errors that originate at Kindo's edge
use the table below; errors that originate upstream are forwarded
verbatim with the upstream body and content-type.

## Envelope

```json
{
  "error": {
    "message": "Model 'unknown-model' not found.",
    "type": "invalid_request_error",
    "code": "model_not_found"
  }
}
```

## Status / type / code reference

| Status | Type                    | Common codes                      | Cause                                                                       |
| ------ | ----------------------- | --------------------------------- | --------------------------------------------------------------------------- |
| `400`  | `invalid_request_error` | `invalid_body`, `model_not_found` | Body fails schema validation or references a missing model.                 |
| `401`  | —                       | —                                 | Missing/malformed/revoked key. Plain envelope: `{"error": "Unauthorized"}`. |
| `403`  | `permission_error`      | `model_access_denied`             | The key authenticated, but the user group does not grant access.            |
| `413`  | —                       | —                                 | JSON request body exceeds the 50 MB (52,428,800-byte) limit. Returned before route handling as `{"message":"Request body too large. Maximum size is 50 MB."}`. |
| `429`  | `rate_limit_error`      | —                                 | Org or user rate limit. Honors `Retry-After` when present.                  |
| `500`  | `server_error`          | `internal_error`                  | Unexpected Kindo-side failure.                                              |
| `502`  | `server_error`          | `upstream_empty_body`             | Upstream returned an empty body.                                            |

Chat Completions does not emit `404` from Kindo's edge — any `404` the client sees is upstream provider passthrough.

### `401` exception

`401` uses the plain-string envelope `{"error": "Unauthorized"}`
rather than the typed `{"error": {"message": "...", ...}}` shape.
This matches Kindo's API-key middleware on `/v1/chat/completions`
and `/v1/responses`.

## Mid-stream errors

Once `stream: true` has flipped the response into SSE, errors arrive
as an inline `event: error` SSE frame followed by `data: [DONE]`:

```
event: error
data: {"error":{"message":"upstream stream interrupted","type":"server_error","code":"stream_error"}}

data: [DONE]

```

Treat any `event: error` payload with `code: "stream_error"` as
terminal. The outer HTTP status stays `200`.

## Provider passthrough

When LiteLLM or the upstream provider returns a 4xx or 5xx with its
own body, Kindo forwards that body verbatim (preserving the upstream
`Content-Type`) so your client sees whatever shape the upstream
produced. Kindo does not rewrap. The exception is
`upstream_empty_body`, which Kindo emits when the upstream returned
an HTTP error with no body so consumers always have a parseable JSON
envelope.

If you want a single consistent error shape across providers, parse
on the outer HTTP status first; only fall back to body inspection
when you need provider-specific detail.

## See also

- [Authentication](/overview/authentication/) — `401` causes.
- [Model catalog](/overview/model-catalog/) — `403` causes.
- [Streaming](/apis/chat-completions/streaming/) — mid-stream error events.

---

## MCP API errors

Source: https://docs.kindo.ai/apis/mcp/errors/

`POST /v1/mcp` can report failures at three levels. HTTP failures
(auth, transport, content negotiation) come back as standard HTTP
responses. JSON-RPC protocol failures come back in a JSON-RPC 2.0
error envelope with HTTP `200`. A valid tool call can instead return
an MCP tool error result.

## HTTP-level errors

| Status | Cause                                                                                                                                                                                                |
| ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `401`  | Missing, malformed, or revoked Bearer token — an API key or a [Cross App Access](/admin/cross-app-access/) token. Response includes a `WWW-Authenticate` header; for an API key it points at the RFC9728 metadata document, for a Cross App Access token see [XAA envelopes](#xaa-envelopes) below.                                                                |
| `403`  | Either the API key is valid but the holder lacks the **Personal API Key Access** entitlement (no `WWW-Authenticate` header; ask your admin to enable it in the user's [group settings](https://app.kindo.ai/?settings=user-groups)), or a Cross App Access token is missing the `kindo.mcp` scope — see [XAA envelopes](#xaa-envelopes).                       |
| `404`  | Path not handled by the MCP gateway. Check the URL — the gateway accepts `POST /v1/mcp` and `GET /.well-known/oauth-protected-resource[/v1/mcp]`.                                                    |
| `406`  | `Accept` header missing `text/event-stream`. Add `Accept: application/json, text/event-stream`.                                                                                                      |
| `413`  | JSON request body exceeds the 50 MB (52,428,800-byte) limit. Returned before MCP handling as `{"message":"Request body too large. Maximum size is 50 MB."}`.                                    |
| `5xx`  | Unexpected gateway failure. Retries are safe; the gateway is idempotent for `tools/list` and `ping`.                                                                                                 |

### `401` envelope

```http
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://api.kindo.ai/.well-known/oauth-protected-resource"
Content-Type: application/json

{ "error": "Unauthorized" }
```

The `WWW-Authenticate` header lets spec-conformant MCP clients
auto-discover that the resource accepts bearer tokens in the
`Authorization` header. Follow the `resource_metadata` URL for
the RFC9728 document — see
[Kindo extensions](/apis/mcp/kindo-extensions/) for the payload shape.

### XAA envelopes

A [Cross App Access](/admin/cross-app-access/) token that fails
verification — expired, the wrong audience or issuer, a bad
signature — gets its own `401` with a `resource_metadata` pointer
and the required scope:

```http
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://api.kindo.ai/.well-known/oauth-protected-resource/v1/mcp", scope="kindo.mcp"
Content-Type: application/json

{ "message": "unexpected \"aud\" claim value" }
```

A token missing the `kindo.mcp` scope gets a `403` instead:

```http
HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope", scope="kindo.mcp", resource_metadata="https://api.kindo.ai/.well-known/oauth-protected-resource/v1/mcp", error_description="access token is missing required scope: kindo.mcp"
Content-Type: application/json

{ "message": "access token is missing required scope: kindo.mcp" }
```

The gateway also rechecks a Cross App Access token's grant on every
call, not just at issuance — the org's Cross App Access configuration
was disabled, the client is no longer approved, the user was
deactivated, or the feature is off for the organization. A recheck
failure returns the same `401` status and the same `WWW-Authenticate`
challenge as a verification failure above, so a caller can't
distinguish the two from status or header alone. The body does differ
in content: a recheck failure always reads
`{ "message": "invalid_token" }`, while a verification failure carries
the verifier's own message (as in the `aud` example above).

## JSON-RPC errors

Protocol-level failures come back with HTTP `200` and a JSON-RPC
2.0 error envelope:

| Code     | Meaning                | Typical cause                                                                                                                            |
| -------- | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `-32000` | Server error           | Custom Kindo errors: `data.reason = "manual_approval_required"` when your organization requires human approval, `"credentials_unavailable"` for revoked/expired credentials, or `"dlp_uninspectable_content"` and `"dlp_unavailable"` — see [data loss prevention](/apis/mcp/dlp/). |
| `-32601` | Method not found       | Unsupported method (`resources/list`, `resources/read`) or a disabled integration's tools.                                                |
| `-32602` | Invalid params         | Unknown tool name, gateway-level invalid parameters, or a tool your account is not authorized to call, including an organization approval setting of **Block**.                                    |
| `-32603` | Internal error         | Unexpected gateway or tool execution failure (`Internal error` or `Tool execution failed`), or organization tool policy could not be loaded or validated (`Unable to load organization tool policy`, refused before execution). |

### `manual_approval_required` envelope

```json
{
  "jsonrpc": "2.0",
  "id": 2,
  "error": {
    "code": -32000,
    "message": "This tool requires human approval and cannot run through external MCP. Use Kindo chat if manual approvals are enabled, or contact your administrator.",
    "data": {
      "reason": "manual_approval_required"
    }
  }
}
```

Your [organization's approval setting](/admin/rbac-tool-actions/#organization-approval-setting)
requires human approval, so the call is
refused before execution. It creates no pending approval request, and retrying
while that setting remains in force produces the same error. Personal tool
settings cannot override this organization requirement.
Use Kindo chat if manual approvals are enabled for your organization; otherwise,
contact your administrator. These tools are also omitted from `tools/list`;
see [Scoping](/apis/mcp/scoping/).

The gateway checks approval before contacting the tool server. A misspelled tool
name on an authorized server can therefore return `manual_approval_required`;
this error does not confirm that the tool exists.

### `credentials_unavailable` envelope

```json
{
  "jsonrpc": "2.0",
  "id": 2,
  "error": {
    "code": -32000,
    "message": "Credentials unavailable for integration linear",
    "data": {
      "reason": "credentials_unavailable",
      "integrationId": "linear",
      "hint": "Reconnect the integration in Settings > Integrations at https://app.kindo.ai/"
    }
  }
}
```

The `hint` URL reflects your deployment's frontend URL —
self-hosted customers see the URL configured for their
deployment, not `app.kindo.ai`.

### DLP envelopes

A result the organization's DLP policy will not let out comes
back as a deliberate `-32000`, never a masked internal error:

```json
{
  "jsonrpc": "2.0",
  "id": 3,
  "error": {
    "code": -32000,
    "message": "Result contains content that cannot be DLP-inspected; blocked by organization policy (fail-closed).",
    "data": {
      "reason": "dlp_uninspectable_content",
      "contentKind": "embedded binary resource"
    }
  }
}
```

`data.reason` is `"dlp_unavailable"` instead when the policy
itself could not be determined or applied. Both are terminal —
retrying produces the same result. See
[data loss prevention](/apis/mcp/dlp/) for which content is redacted and
which is blocked.

## MCP tool errors

A call to a valid `platform_*` tool with arguments that do not match
the tool's schema returns a successful JSON-RPC response whose result
is a `CallToolResult` with `isError: true`. The text content is a JSON
error body:

```json
{
  "content": [
    {
      "type": "text",
      "text": "{\"code\":\"invalid_input\",\"message\":\"agent_id must be a valid UUID\",\"retryable\":false}"
    }
  ],
  "isError": true,
  "_meta": {
    "kindo.dev/platform-tool-error": 1
  }
}
```

Read the text value as JSON to inspect the error. The versioned
`_meta` marker identifies this Platform tool error format.

Directory and department tools also use this format when a tool-specific access
check fails: `code` is `not_found`, and `message` names the missing admin role,
department access, or plan requirement. This can happen when calling a previously
discovered tool after access is revoked; it does not necessarily mean the
requested user or department is missing.

## Common failure modes

- **`406 Not Acceptable: Client must accept both application/json and text/event-stream`** —
  Your client is missing `Accept: application/json, text/event-stream`. Add
  it. MCP SDKs and `mcp-remote` set it for you; only raw HTTP
  callers hit this.
- **`-32000 credentials_unavailable`** — Your connection's
  credentials have been revoked or have expired. Reconnect the
  integration in **Settings > Integrations** at
  [https://app.kindo.ai/](https://app.kindo.ai/)
  (or your self-hosted deployment's equivalent).
- **`-32602 Invalid params` with "tool not found"** — Check the
  tool name prefix. Tools are named `{integration}_{name}`
  (underscore, not colon). For example, `linear_get_issue`, not
  `linear:get_issue`. Integration IDs containing hyphens still
  use one underscore as the separator: `sap-s4hana-rfc_invoke_bapi`.
- **`401` with `WWW-Authenticate: Bearer`** — The API key is
  missing, malformed, or revoked. Verify the key is present and
  well-formed. The gateway does **not** fall back from a
  malformed `Authorization` header to `x-api-key`.
- **`401` with `{ "message": "invalid_token" }` from a Cross App
  Access token** — The token verified, but its grant is no longer
  valid: the org's configuration was disabled, the client is no
  longer approved, the user was deactivated, or the feature is off
  for the organization. The response doesn't say which — see
  [XAA envelopes](#xaa-envelopes).
- **Empty `tools/list`** — Your account has no integrations
  connected, or you passed an `?integrations=` filter that
  matches nothing your account can reach, or your organization's approval
  setting is **Ask before running** or **Block**. See
  [Scoping](/apis/mcp/scoping/).

## See also

- [Quickstart](/apis/mcp/quickstart/) — first successful call.
- [Request shape](/apis/mcp/request-shape/) — supported methods and
  required headers.
- [Scoping](/apis/mcp/scoping/) — why a tool may not appear for your
  account.

---

## Messages API errors

Source: https://docs.kindo.ai/apis/messages/errors/

`POST /v1/messages` returns errors using Anthropic's standard error
envelope. Errors that originate at Kindo's edge use the table below;
errors that originate upstream are forwarded verbatim with the
upstream body and content-type.

## Envelope

```json
{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "max_tokens is required"
  }
}
```

## Status / type / code reference

| Status | Type                    | Common codes | Cause                                                                                                               |
| ------ | ----------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------- |
| `400`  | `invalid_request_error` | —            | Body fails schema validation (missing `max_tokens`, malformed `messages`, etc.), references a missing model, or is blocked by org DLP policy (e.g. binary document attachments that cannot be redacted). |
| `401`  | `authentication_error`  | —            | Missing, malformed, or revoked API key.                                                                             |
| `403`  | `permission_error`      | —            | The key authenticated, but the user group does not grant access.                                                    |
| `413`  | —                       | —            | JSON request body exceeds the 50 MB (52,428,800-byte) limit. Returned before route handling as `{"message":"Request body too large. Maximum size is 50 MB."}`. |
| `429`  | `rate_limit_error`      | —            | Org or user rate limit. Honors `Retry-After` when present.                                                          |
| `500`  | `api_error`             | —            | Unexpected Kindo-side failure.                                                                                      |
| `502`  | `upstream_empty_body`   | —            | Upstream returned an empty body. Example: `{"type":"error","error":{"type":"upstream_empty_body","message":"..."}}` |

### `401` note

On `/v1/messages`, `401` returns Anthropic's typed `authentication_error` envelope rather than the plain-string `{"error":"Unauthorized"}` shape used on `/v1/chat/completions` and `/v1/responses`.

```json
{
  "type": "error",
  "error": {
    "type": "authentication_error",
    "message": "Unauthorized"
  }
}
```

The Messages API uses Anthropic's typed envelope, which includes `type` but not a separate `code` field. (This differs from the Chat Completions and Responses APIs, where errors include both `type` and `code`.)

## Mid-stream errors

If `stream: true` has flipped the response into SSE, errors arrive
as an `event: error` frame before the stream terminates:

```
event: error
data: {"type":"error","error":{"type":"overloaded_error","message":"upstream overloaded"}}
```

The outer HTTP status stays `200` because headers were already
flushed when streaming began. SDK consumers should treat any
mid-stream `error` event as terminal.

## Provider passthrough

When an upstream provider (Anthropic, etc.) returns a 4xx or 5xx
with its own body, Kindo forwards that body verbatim, preserving the
upstream `Content-Type`. Your client sees whatever shape the
upstream produced. The exception is
`upstream_empty_body`, which Kindo emits (as the value of `error.type`) when the upstream returned
an HTTP error with no body so consumers always have a parseable JSON
envelope.

If you want a single consistent error shape across providers, parse
on the outer HTTP status first; only fall back to body inspection
when you need provider-specific detail.

## See also

- [Authentication](/overview/authentication/) — `401` causes.
- [Model catalog](/overview/model-catalog/) — `403` causes.
- [Streaming](/apis/messages/streaming/) — mid-stream error events.

---

## Responses API errors

Source: https://docs.kindo.ai/apis/responses/errors/

`POST /v1/responses` returns errors in OpenAI's Responses error
envelope. Errors that originate at Kindo's edge use the table
below; errors that originate upstream are forwarded verbatim with
the upstream body and content-type.

## Envelope

```json
{
  "error": {
    "message": "Model 'unknown-model' not found.",
    "type": "invalid_request_error",
    "code": "model_not_found"
  }
}
```

## Status / type / code reference

| Status | Type                    | Common codes                                               | Cause                                                                                                                              |
| ------ | ----------------------- | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| `400`  | `invalid_request_error` | `invalid_body`, `model_not_found`, `unsupported_parameter`, `unsupported_tool_type`, `mutually_exclusive_parameters` | Body fails schema validation, references a missing model, asks for a feature not yet implemented (e.g. `background: true` on a Kindo-managed conversation), includes an `mcp` tool on a stateless request (set `store: true` or pass `conversation`), or sets both `previous_response_id` and `conversation`. |
| `400`  | `invalid_request_error` | `agent_version_pinning_unsupported`, `agent_inputs_unmappable` | Agent invocations (`model: "agent/<agent-id>"`): version pinning (`agent/<id>@<version>`) is not available yet; or the agent's declared inputs cannot be bound to a freeform `input` — it declares two or more named inputs, or a single non-text input (use [`POST /v1/agents/runs`](/apis/agents/runs/) with named inputs instead). `model_not_found` also covers unknown **and inaccessible** agent IDs — indistinguishable from an unknown model. See [the agent invocation guide](/guides/invoke-agents-responses-api/#errors). |
| `401`  | —                       | —                                                          | Missing, malformed, or revoked API key. The body is a plain string envelope: `{"error": "Unauthorized"}`.                          |
| `403`  | `permission_error`      | `model_access_denied`                                      | The key authenticated, but the user group does not grant access to the model.                                                      |
| `404`  | `not_found`             | —                                                          | E.g. `GET /v1/responses/{id}` for a response that does not exist or has been pruned.                                               |
| `404`  | `invalid_request_error` | `previous_response_not_found`                              | `previous_response_id` references a response that is unknown, inaccessible, or was not stored (stateless responses cannot be chained). Matches OpenAI's wire shape for this error. |
| `413`  | —                       | —                                                          | JSON request body exceeds the 50 MB (52,428,800-byte) limit. Returned before route handling as `{"message":"Request body too large. Maximum size is 50 MB."}`. |
| `429`  | `rate_limit_error`      | —                                                          | Org or user rate limit exceeded. Honors the `Retry-After` header when present.                                                     |
| `500`  | `server_error`          | `internal_error`                                           | Unexpected Kindo-side failure.                                                                                                     |
| `502`  | `server_error`          | `upstream_empty_body`                                      | Upstream LiteLLM / provider returned an empty response.                                                                            |

### `401` exception

The `401` envelope is the plain-string form
`{"error": "Unauthorized"}` rather than the typed
`{"error": {"message": "...", "type": "...", "code": "..."}}` shape.
This matches how Kindo's API-key middleware reports auth failures
across the Chat Completions and Responses APIs.

## Mid-stream errors

If `stream: true` is set and an error occurs after the SSE has
started, Kindo emits an `error` event followed by `response.failed`:

```
event: error
data: {"error":{"message":"upstream stream interrupted","type":"server_error","code":"stream_error"}}

event: response.failed
data: {"id":"resp_abc123","status":"failed","object":"response"}
```

The outer HTTP status stays `200` because headers were already
flushed when streaming began. SDK consumers should treat any
mid-stream `error` event as terminal.

See [Streaming](/apis/responses/streaming/) for the full SSE protocol.

## Provider passthrough

When an upstream provider (Anthropic, OpenAI, etc.) returns a 4xx or
5xx with its own body, Kindo forwards that body verbatim, preserving
the upstream `Content-Type`. Your client sees whatever shape the
upstream produced — Kindo does not rewrap. The exception is
`upstream_empty_body`, which Kindo emits when the upstream returned
an HTTP error with no body so consumers always have a parseable JSON
envelope to log.

If you want a single consistent error shape across providers, parse
on the outer HTTP status first; only fall back to body inspection
when you need provider-specific detail.

## See also

- [Authentication](/overview/authentication/) — `401` causes.
- [Model catalog](/overview/model-catalog/) — `403` causes.
- [Streaming](/apis/responses/streaming/) — mid-stream error events.
- [Response store pruning](/apis/responses/request-shape/#response-store-pruning) — `404` causes.

---

## Child Agent Output Size Limits

Source: https://docs.kindo.ai/best-practices/child-agent-output-limits/

When one Kindo agent invokes another as a child agent, the child's result is summarized for the parent agent and the verbatim transcript is parked alongside the run — fetched on demand rather than pushed back inline. Kindo bounds the size of any transcript the parent reads so multi-agent setups stay reliable even when the child produces large amounts of evidence — log dumps, Splunk result sets, verbose API responses, or any other bulky output.

## What the parent receives on completion

When a child agent finishes, the parent's tool call result contains a single structured object:

- A short **summary** of what the child did and concluded.
- A list of **key findings** — the most important facts, data points, or decisions.
- A **confidence** signal — high, medium, or low.

The summary, key findings, and confidence are the distilled, high-signal channel and the parent's primary input. The full conversation transcript is **not** included in this result.

## Reading a child's transcript

When the parent agent needs to inspect what a child actually did — to spot-check a finding, quote evidence, or debug a confusing result — it calls the **`get_child_agent_transcript`** tool, passing the child's `workflowRunId`. The tool works in two steps:

1. **Outline first.** The default response is a compact map of the transcript: how many turns it has, its total size, and one line per turn — who spoke and a short preview of what was said. This costs the parent agent very little context, however large the child's transcript is.
2. **Read what matters.** The parent agent then requests the full text of just the turns it needs — typically the child's closing turns, or the span around a finding it wants to verify. The text comes back as role-tagged turns (`[USER]`, `[ASSISTANT]`, etc.) in conversation order.

Children that are still running return their transcript so far. A parent can only read transcripts of children it spawned.

## Access control for child-agent tools

`list_child_agents` and `get_child_agent_transcript` are scoped to the child agents spawned by the parent. A parent sees and can read transcripts of only the agents it spawned itself; children spawned elsewhere in your workspace are not visible to it.

## What "bounded" means

Both steps are bounded, so a parent agent's context window is protected no matter what the child produced:

- The **outline** is compact by construction — previews are one short line per turn, and extremely long transcripts list their opening and closing turns with the middle elided (those turns remain readable on request).
- Each **read** returns at most **48 KiB** (49,152 bytes, measured as UTF-8 byte length) of transcript text. Reads are assembled from **whole turns**: when the requested span doesn't fit in one response, the read stops at a turn boundary and tells the parent agent where to continue. No content is ever lost to the cap — larger spans just take more than one read. (The per-read text limit sits below the parent's overall inline tool-result budget so the read, once wrapped in its JSON response envelope, is always delivered in full rather than parked in external storage.)

The one exception is a single turn that is by itself larger than one read — for example a turn into which a child pasted an entire log dump. In that case Kindo keeps the **beginning and the end** of that turn, drops the middle (cutting on safe character boundaries), and signals the cut explicitly — both inline, with a marker at the cut, and as a structured `transcript_overflow` field:

```json
{ "originalBytes": 196608, "keptBytes": 49152 }
```

Both counts are UTF-8 byte lengths: `originalBytes` is the turn's full size before truncation, `keptBytes` is the size of the returned text. The field is present **only when a turn was cut**, so a parent agent can branch on it to detect truncation programmatically rather than parsing the inline marker.

## Designing child agents that surface findings reliably

### Make the final step produce a tight, decision-ready summary

The summarizer that builds the parent-visible result works on the child's whole conversation. The more compact and structured the child's final messages are, the more useful the parent-visible summary and key findings will be. A child agent whose last step is "produce a short structured conclusion" is far more useful to a parent than one whose last step dumps a thousand lines of evidence.

### Treat the transcript as evidence, not as context

Design parent prompts to read the summary and key findings first, and reach for `get_child_agent_transcript` only when a specific detail is needed. The outline-then-read flow supports this naturally: the parent agent can check the outline cheaply, then pull only the turns that matter, instead of reading the whole transcript front to back.

### Externalize bulk evidence

If a child agent's job is to produce a large artifact — a report, an export, a long log bundle — write it to an external system (Notion, Google Drive, a ticketing system, an S3 bucket via an API Action step) and have the child return a pointer plus a short summary. The parent agent can fetch the full artifact via an integration when needed, rather than carrying it in conversation context.

### Read further instead of reasoning from partial data

A transcript larger than one read is not lost — the parent agent can keep reading until it has what it needs. The `transcript_overflow` field appears only when one giant turn had to be cut; in that case the summary, key findings, and confidence value remain the high-signal channel for that turn's content. If a child routinely produces single turns too large to read whole, narrow the child's prompt or split the work across more focused child runs.

## When child agents are the wrong tool

Child agents are designed for delegating a bounded task and getting a summarized answer back. If an agent's natural shape is "produce a large dataset and hand it to the next step verbatim," consider keeping the work inside one agent — using multiple steps in a single run so intermediate data never has to cross the parent/child boundary — or coordinating via an external system so bulk data is passed through storage rather than conversation context.

## Related

- [Multi-Agent Coordination](/best-practices/multi-agent-coordination/) — patterns for splitting work across parent and child agents.
- [Working with Large Context](/best-practices/working-with-large-context/) — managing context window pressure in any agent.

---

## MCP API — Kindo extensions

Source: https://docs.kindo.ai/apis/mcp/kindo-extensions/

By default, `POST /v1/mcp` is a stock spec-conformant MCP server.
Kindo adds two opt-in extensions on top of the spec:

1. **Integration filter** — narrow `tools/list` to a specified
   subset of your integrations.
2. **Connection management REST endpoints** — list connections and
   select a preferred connection for each integration.

Use these when you need them; ignore them and the gateway still
works.

## 1. Integration filter

Pass an explicit allow-list as either a query parameter or a
header, and `tools/list` returns only those integrations'
tools:

```bash
# Query parameter
curl -X POST "https://api.kindo.ai/v1/mcp?integrations=linear,github" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{ "jsonrpc": "2.0", "method": "tools/list", "id": 1 }'

# Header (equivalent)
curl -X POST https://api.kindo.ai/v1/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -H "x-kindo-integrations: linear,github" \
  -d '{ "jsonrpc": "2.0", "method": "tools/list", "id": 1 }'
```

The filter narrows the set you would otherwise see — it never
grants access. If your account can't reach `github` and you ask
for `?integrations=linear,github`, you get only Linear tools back
(no error). Both forms accept comma-separated values; the query
parameter also accepts the array repetition form
(`?integrations=linear&integrations=github`). If both query and
header are present, the query parameter wins.

For the underlying rules — which integrations your account can
reach in the first place — see [Scoping](/apis/mcp/scoping/).

## 2. Connection management REST endpoints

These are regular Kindo REST endpoints, not MCP methods. Use them to list
your connections and select a single preferred connection for an integration.
Your active connections also serve as personal defaults for Kindo chats and agents.

### `GET /v1/integrations/connections`

Returns all integration connections accessible to the API-key
holder, including shared group connections. Each entry's `is_preferred`
field indicates whether it belongs to your active connection set for that
integration. Several connections can have `is_preferred: true`.

```bash
curl https://api.kindo.ai/v1/integrations/connections \
  -H "Authorization: Bearer $KINDO_API_KEY"
```

```json
{
  "data": [
    {
      "id": "conn_abc123",
      "display_name": "Charlie's Linear",
      "integration_config_id": "linear",
      "nango_connection_id": "nango_conn_1",
      "is_preferred": true,
      "created_at": "2026-03-10T18:45:23.000Z"
    }
  ]
}
```

### `POST /v1/integrations/connections/{integration_id}/default`

Sets the specified connection as your only active connection for an integration.
`{integration_id}` is the same value as `integration_config_id`
returned by the list endpoint (e.g., `linear`, `github`).

This replaces your entire active connection set for that integration with the
specified connection. It also changes the personal defaults used by Kindo
chats and agents that do not have pinned connections.

```bash
curl -X POST https://api.kindo.ai/v1/integrations/connections/linear/default \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{ "connection_id": "conn_abc123" }'
```

```json
{
  "integration_config_id": "linear",
  "connection_id": "conn_abc123"
}
```

| Code  | Meaning                                                                                                    |
| ----- | ---------------------------------------------------------------------------------------------------------- |
| `400` | Invalid request body — `connection_id` is required, or `connection_id` does not belong to `integration_id`. |
| `403` | Forbidden — you are not authorized to use this connection.                                                  |
| `404` | Integration connection not found (or you do not have access to view it).                                    |

Once set, the default flows through to `tools/call` resolution.
See [Scoping → Default-connection resolution](/apis/mcp/scoping/#default-connection-resolution)
for where your preferred connection sits in the resolution chain.

## RFC9728 discovery

Kindo serves an [RFC 9728](https://www.rfc-editor.org/rfc/rfc9728)
Protected Resource Metadata document so MCP clients can
auto-discover the bearer-token authentication mode:

- `GET https://api.kindo.ai/.well-known/oauth-protected-resource`
- `GET https://api.kindo.ai/.well-known/oauth-protected-resource/v1/mcp`

Both return the same document, with the second path provided for
clients that follow RFC9728's path-scoped lookup rule. The body
confirms bearer-header mode:

```json
{
  "resource": "https://api.kindo.ai/v1/mcp",
  "bearer_methods_supported": ["header"],
  "authorization_servers": ["https://api.kindo.ai/oauth"],
  "scopes_supported": ["kindo.mcp"]
}
```

Tokens are plain bearer tokens — Kindo does not support DPoP-bound tokens on
this resource.

The `authorization_servers` entry is a real issuer, not a placeholder — but a
narrow one. It supports only the ID-JAG `urn:ietf:params:oauth:grant-type:jwt-bearer`
grant, and only for an organization with
[Cross App Access](/admin/cross-app-access/) enabled: an admin approves an
Okta app to redeem an Okta-issued ID-JAG for a short-lived Kindo MCP access
token scoped to `kindo.mcp`, on behalf of a signed-in user. It does not
support `authorization_code` or dynamic client registration, and static
Kindo API keys remain the default way to call `/v1/mcp` — most integrations
never need this issuer.

## See also

- [Scoping](/apis/mcp/scoping/) — the deeper read on what tools your
  account can reach.
- [Errors](/apis/mcp/errors/) — the `WWW-Authenticate` header tied to
  RFC9728 discovery.

---

## Responses API — Chat Actions extensions

Source: https://docs.kindo.ai/apis/responses/kindo-extensions/

By default, `POST /v1/responses` behaves like stock OpenAI Responses
— no hidden system prompt, no auto-injected tools, no server-side
state. **Chat Actions** are three orthogonal opt-ins layered on top:

1. **Curated system prompt** — let Kindo prepend its operational
   prompt to your `instructions`.
2. **Kindo-hosted tools** — call `kindo_shell`, `kindo_web_search`,
   and the rest of the Kindo tool catalog.
3. **Stateful conversations** — let Kindo persist responses
   server-side so subsequent turns chain off them.

Each is independent. Mix and match. (If you find yourself combining
all three to recreate one of your stored agents, invoke the agent
itself instead: `model: "agent/<agent-id>"` — see
[Invoke Kindo agents](/guides/invoke-agents-responses-api/).)

## 1. Curated system prompt

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "input": "Investigate the crashloop on api-prod-2.",
  "kindo": { "system_prompt": "agent_default" }
}
```

| `kindo.system_prompt` value | Behavior                                                                                                                                                                                                                                                                                     |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `"agent_default"`           | Kindo prepends its curated operational prompt to your `instructions`. On stateful requests (`store: true`, `conversation`, or `previous_response_id`), Kindo includes service-managed context with the composed prompt and supplies the current date and timezone with the triggering input. |
| `"off"` (default)           | Default `"off"` does not prepend Kindo's curated prompt or add service-managed prompt or input context; client instructions and input remain unchanged.                                                                                                                                      |

On compacted stateful turns, a service-managed compaction hint may be
appended; it follows composed instructions and other service-managed
prompt guidance. With `off`, caller instructions are preserved; the
separate compaction hint may still be added.

If you also pass `instructions`, Kindo prepends its prompt and your
`instructions` flow after it. On stateful requests, Kindo also includes
service-managed context with the managed prompt and triggering input.
Use this when you want Kindo's curated agent behavior on top of your
own task guidance.

## 2. Kindo-hosted tools

You have two ways to opt in to Kindo's hosted tools.

### 2a. The full bundle (`kindo_tools` sugar)

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "input": "...",
  "tools": [{ "type": "kindo_tools" }]
}
```

`{type: "kindo_tools"}` is documented sugar. At request time Kindo
expands it into the current set of individual `kindo_<name>` entries
the model can call.

### 2b. Individual tools

Pick the ones you actually want:

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "input": "...",
  "tools": [{ "type": "kindo_shell" }, { "type": "kindo_web_search" }]
}
```

The full hosted-tool catalog:

| Tool type                              | Purpose                                                                                                         |
| -------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| `kindo_shell`                          | Run a sandboxed shell command on a Kindo-managed agent workstation.                                             |
| `kindo_web_search`                     | Search the web.                                                                                                 |
| `kindo_browser_control`                | Drive a headless browser session.                                                                               |
| `kindo_browser_screenshot`             | Capture a screenshot of the current page.                                                                       |
| `kindo_browser_list_network_requests`  | List network requests captured by the browser tool.                                                             |
| `kindo_browser_export_request_as_curl` | Export a captured request as a runnable curl command.                                                           |
| `kindo_file_read`                      | Read a file the agent has access to.                                                                            |
| `kindo_file_write`                     | Write to a file the agent has access to.                                                                        |
| `kindo_file_list`                      | List files in an accessible directory.                                                                          |
| `kindo_web_download`                   | Download a URL to the agent workspace.                                                                          |
| `kindo_files_download_original`        | Fetch the original binary of a previously stored file.                                                          |
| `kindo_files_download_as_text`         | Fetch a previously stored file as decoded text.                                                                 |
| `kindo_file_share_with_user`           | Share a file with a Kindo user. The download URL is in the `kindo_call` item's `output`, not in assistant text. |
| `kindo_vpn_connect`                    | Connect the agent's network egress to an organization VPN.                                                      |
| `kindo_vpn_disconnect`                 | Disconnect from the organization VPN.                                                                           |
| `kindo_dashboard_generate`             | Generate a Kindo dashboard.                                                                                     |
| `kindo_dashboard_update`               | Update a Kindo dashboard.                                                                                       |
| `kindo_knowledge_store_search`         | Search a Kindo knowledge store.                                                                                 |

Tool types not in this list are forwarded verbatim to LiteLLM
(passthrough) — useful when a new upstream tool type ships before
our docs do.

You can mix Kindo-hosted tools with stock OpenAI types
(`function`, `mcp`, `web_search`, `file_search`, `computer`, …) in
the same `tools` array. `tool_choice` (including `allowed_tools`)
applies uniformly. Note that `mcp` tools require the stateful path
(`store: true` or `conversation` — see [Stateful
conversations](#3-stateful-conversations)); stateless requests
including them are rejected with `400 unsupported_tool_type`.

## 3. Stateful conversations

Stock OpenAI Responses on `/v1/responses` is stateless by default.
Kindo offers two forms of stateful continuation: `conversation` (the
Kindo-managed conversation ID) and `previous_response_id` (chain from
a previous stored response, as the OpenAI SDK and Codex do by
default). They are mutually exclusive — two spellings of the same
continuation intent.

### `conversation`

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "input": "Continue the investigation.",
  "store": true,
  "conversation": "conv_xyz789"
}
```

`conversation` is the Kindo-managed equivalent and is what the
existing `/v1/responses` flow returns in
`response.conversation.id`.

### `previous_response_id`

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "input": "Continue the investigation.",
  "previous_response_id": "resp_xyz789_1"
}
```

Pass the `id` of a previous **stored** response (one created with
`store: true` or `conversation`) to continue the conversation that
produced it — this is how the OpenAI SDK and Codex chain turns by
default. It is equivalent to passing that conversation's ID via
`conversation`, and the two parameters are mutually exclusive
(`400 mutually_exclusive_parameters` if both are set). Unknown,
inaccessible, or unstored response IDs return
`404 previous_response_not_found` — stateless responses are never
persisted, so their IDs cannot be chained. Kindo conversations are
linear: chaining from an older response continues the full
conversation history rather than forking at that response.

With either continuation mechanism the full prior history is loaded
server-side and sent to the model — send only the new turn in
`input`. Use `conversation` when you have a Kindo-managed
conversation ID; use `previous_response_id` when you have the last
response's ID (the OpenAI-native pattern); otherwise start a new
request with `store: true` and use the returned `conversation.id` or
response `id` for subsequent turns.

Long stored conversations are compacted automatically.
When the accumulated history approaches the model's context window,
Kindo summarizes earlier turns server-side before sending the
conversation to the model, so a long-running stored conversation keeps
working without manual truncation on your side. Compaction is applied
transparently — it does not change the response shape or emit a
separate streaming event.

## Putting it together

If you previously relied on `tools: [{type: "kindo_tools"}]` as a
mode switch that implicitly turned on the curated prompt and
statefulness, this is the equivalent explicit recipe:

```json
{
  "model": "claude-sonnet-4-5-20250929",
  "input": "...",
  "store": true,
  "kindo": { "system_prompt": "agent_default" },
  "tools": [{ "type": "kindo_tools" }]
}
```

Three opt-ins, all visible in the request body. None are implicit.

## See also

- [Chat Actions overview](/guides/chat-actions/) — conceptual
  overview of the three opt-ins. `/v1/chat/completions` and
  `/v1/messages` are stock OpenAI / stock Anthropic and do not
  accept these extensions.
- [Quickstart](/apis/responses/quickstart/) — stock-OpenAI baseline, no
  extensions.
- [Request shape](/apis/responses/request-shape/) — every standard field, plus
  the `kindo` block.
- [Tool use](/apis/responses/tool-use/) — function-tool round trip; mixes with
  hosted tools in the same `tools` array.

---

## Kindo Best Practices

Source: https://docs.kindo.ai/best-practices/

This section collects practical guidance for running Kindo well in production. It focuses on two areas that become increasingly important as usage scales: how you manage agent configuration over time, and how you keep large-context agents reliable.

## In This Section

## Security Scenarios

Step-by-step guides for common security automation scenarios:

## When to Use These Guides

- **Rolling out production agents** that multiple teams will depend on
- **Creating shared standards** for prompt reviews, change management, and ownership
- **Improving reliability** for agents that process large documents, logs, or tool outputs
- **Preparing self-managed deployments** where documentation and governance need to be explicit

---

## MCP API data loss prevention

Source: https://docs.kindo.ai/apis/mcp/dlp/

When your organization has gateway DLP enabled, tool data your
MCP client fetches through `POST /v1/mcp` is subject to your
organization's data loss prevention (DLP) policy before it
leaves Kindo: the gateway redacts what the policy says to
redact, and refuses to return content it cannot inspect. For
organizations without gateway DLP enabled, results pass through
unchanged.

This is the same DLP engine and the same redaction
representation you see on the Kindo chat and model APIs. What
differs is how the policy is selected.

## The policy is provider-neutral

On the chat and model APIs, DLP resolves against the model and
provider that will serve the request. An external MCP client
calls its own model directly, so the gateway has no downstream
model — and it will not take one from the client, because a
client-declared model could be used to select a weaker policy.

Instead, the gateway resolves the policy from what it can verify
about the caller:

- your organization's DLP settings for the **integration** the
  tool belongs to;
- the DLP settings of every **user group** you belong to;
- and the DLP settings of the **individual tool** being called,
  which take precedence over the integration's when both
  configure filters.

The result is the **strictest** combination: if any of those
levels redacts an entity type, it is redacted. Because the
policy is resolved on every call, an administrator's change
takes effect on your next request — there is nothing to refresh
or reconnect.

Administrators configure this under
[**Settings > Integrations**](https://app.kindo.ai/?settings=security/integrations-and-tools).
Organizations with no integration-level DLP configured see
results returned exactly as the upstream server produced them.

## What gets redacted

| Part of the result | Treatment |
| ------------------ | --------- |
| `text` content items | Redacted. |
| `structuredContent` | Every string value is redacted, at any depth. The JSON structure is preserved. |
| Embedded resources with inline `text` | The text is redacted. |
| `resource_link` items | `name`, `title`, and `description` are redacted. The `uri` is returned unchanged so the link keeps working. |
| Results with `isError: true` | Redacted like any other result — error text is tool output and often quotes the record that failed. |
| `image` content items | Returned unchanged. Images carry no text the DLP engine reads. |

Redactions use the DLP engine's entity placeholders — an email
address becomes ``, a US social security number
becomes ``, and so on. Custom phrase and pattern filters
your administrator has configured are replaced with `REDACTED`.

## What gets blocked

Some content cannot be inspected: Kindo cannot read it, so it
cannot redact it, and returning it would make an opaque payload
the way around the policy. When DLP is enabled for the
integration, a result containing any of the following is
**blocked in full** rather than partially returned:

- embedded resources carrying a binary `blob`;
- `audio` content items;
- any content type Kindo does not recognize.

The call fails with a JSON-RPC `-32000` error and
`data.reason = "dlp_uninspectable_content"`. If DLP is not
enabled for the integration, this content is returned normally.

A DLP outage is treated the same way: if the policy cannot be
determined or applied, the call fails with `-32000` and
`data.reason = "dlp_unavailable"`. Kindo does not fall back to
returning unredacted data.

Both envelopes are documented in [MCP API errors](/apis/mcp/errors/).

## What this means for your client

- **Handle `-32000` as terminal, not retryable.** A block is a
  policy decision. Retrying returns the same error; the fix is a
  policy change or a tool that returns inspectable content.
- **Expect placeholders in tool output.** A tool that returns an
  email address may return `` instead. Do not
  treat a placeholder as a literal value to write back.
- **Prefer tools that return text or structured content** over
  tools that return binary attachments, if your organization
  enables gateway DLP — text and structured content are
  redactable, attachments are not.

---

## 'Memory and Persistence Patterns'

Source: https://docs.kindo.ai/best-practices/memory-and-persistence/

Kindo agents use run-scoped memory by default, and agent owners can enable a per-user, per-agent persistent sandbox when files and state should carry across that user's runs. This guide covers the built-in persistence options and patterns for extending memory with external systems.

:::note[Looking for the Memory feature?]
This page is about **file and state persistence** — sandboxes, knowledge stores, and external systems that carry an agent's working data across runs. Kindo's [Memory feature](/features/memory/) (the Memory Engine) is a separate capability: it captures durable *facts* from conversations and recalls them in later ones. See the [glossary](/reference/glossary/) for how the memory-related terms differ.
:::

## Overview

Kindo scopes agent memory to individual runs by default. The platform also offers an opt-in **per-user, per-agent persistent sandbox** for agents whose owners turn it on, and the patterns below extend memory further using integrations and external systems:

| Pattern                        | Scope                  | Read             | Write              | Durability         | Complexity |
| ------------------------------ | ---------------------- | ---------------- | ------------------ | ------------------ | ---------- |
| **Knowledge Store**            | Org-wide               | ✅               | ❌ (manual upload) | High               | Low        |
| **Sandbox**                    | Single run             | ✅               | ✅                 | None (ephemeral)   | Low        |
| **Persistent Sandbox**         | Per-user, per-agent    | ✅               | ✅                 | Across runs        | Low        |
| **External System**            | Cross-workflow         | ✅ via API/MCP   | ✅ via API/MCP     | High               | Medium     |
| **Git Repository**             | Team-wide              | ✅ (manual sync) | ✅ (commits)       | Very high          | Medium     |

## Pattern 1: Knowledge Store — Static Reference Data

### When to Use

- Agent needs access to policies, runbooks, compliance frameworks, threat intel feeds
- Data changes infrequently (updated by humans, not agents)

### How It Works

1. Upload files to Knowledge Store (PDF, markdown, CSV, etc.)
2. Attach Knowledge Store to agent(s) — multiple agents can share the same files
3. Agent references files via Library Search or direct attachment

### Limitations

- **Read-only:** Agents cannot update Knowledge Store files
- **Manual upload:** No API for programmatic updates
- **File size limits:** Apply to uploads

### Example

Upload your organization's incident response playbook as a PDF. Attach it to all SOC agents — they reference it when classifying incidents.

## Pattern 2: Sandbox — Ephemeral Per-Run Memory

### When to Use

- Intermediate results within a multi-step workflow
- Large data that needs filtering before LLM processing
- Temporary files (scripts, extracted data, reports)

### How It Works

1. API Action steps and tool outputs write to the sandbox automatically when large
2. LLM steps can read/write sandbox files using shell commands
3. Data persists for the duration of the workflow run, then is discarded

### Cross-Reference

→ See [Working with Large Context](/best-practices/working-with-large-context/) for detailed sandbox techniques

### Limitations

- **Ephemeral:** Gone after the run ends
- **Not shareable:** Between agents or runs

## Pattern 3: Persistent Sandbox — Per-User, Per-Agent Memory Across Runs

### When to Use

- Agent needs to keep files, scripts, or working state across runs (e.g., a long-running research agent that builds up notes, or a code agent that maintains a working checkout)
- You want the durability of a sandbox without writing to an external system

### How It Works

1. The agent owner opens the agent's settings and turns on **Persistent Workspace**.
2. Each user who runs that agent gets their own isolated persistent sandbox — files and state created during a run are still there on that user's next run of the same agent.
3. When the toggle is off, behavior is unchanged from Pattern 2 (single-run, ephemeral).

### Per-User Isolation — Important

Persistent sandboxes are scoped to **(user, agent)**, not just to the agent. If you and a teammate both run the same shared agent with persistent workspace enabled, you each get your own private sandbox. Files written during your runs are **not** visible to your teammate, and vice-versa.

This is intentional. It means:

- **Sharing the agent does not share its filesystem state.** A user who runs a shared agent does not see anything other users wrote into that agent's sandbox.
- **Concurrent runs by the same user share the same sandbox.** Two simultaneous runs by you against the same persistent-sandbox agent will see and write to the same filesystem. Plan for that the same way you'd plan for two processes sharing a directory.
- **Team-level shared persistent sandboxes are not supported.** If multiple users genuinely need to share state across runs, use Pattern 4 (External Systems) so the read/write path is auditable and consent-based.

### Limitations

- **Per-user, not per-team:** see above.
- **Sharing an agent does not share its sandbox state.** Recipients of a shared persistent-sandbox agent get a fresh sandbox keyed to their user identity on first run.
- **Availability:** the feature requires a sandbox provider that supports persistence, such as OpenShell or Daytona. On other providers, the Persistent Workspace toggle does not appear.

### Cross-Reference

→ See [Working with Large Context](/best-practices/working-with-large-context/) for sandbox techniques that apply to both ephemeral and persistent sandboxes.

## Pattern 4: External Systems — Persistent Cross-Workflow Memory

### When to Use

- Agent needs to remember findings from previous runs
- Multiple agents need to share state (e.g., investigate → remediate pipeline)
- Audit trail required for agent decisions

### How It Works

**Write:** Use API Action steps to create/update records in external systems:

- Create Jira tickets with structured findings
- Post to Slack channels as a persistent log
- Write to Notion/Confluence pages
- Push to Google Sheets for tabular data

**Read:** Use API Action steps at the start of a workflow to load previous state:

- Query Jira for tickets created by previous agent runs
- Read from a designated Notion "agent memory" page
- Fetch latest entries from a Google Sheet

### Architecture

```
Agent run N writes structured JSON to Notion page
    ↓
Agent run N+1 reads that page as first step
    ↓
Processes new data
    ↓
Writes updated state back
```

### Example: Vulnerability Tracking Over Time

1. Weekly scan agent writes top 10 findings to a Notion database
2. Each row: CVE, severity, first seen date, current status, remediation owner
3. Next week's run reads the database → compares with new scan → updates statuses → adds new findings → flags regressions

### Design Considerations

- **Choose familiar systems:** Use tools your team already uses (don't add new tools just for agent memory)
- **Use structured formats:** JSON in Jira custom fields, database rows in Notion — so agents can parse reliably
- **Include provenance:** Timestamps and run IDs so you can trace which agent run wrote what
- **Consider rate limits:** Especially for high-frequency scheduled agents hitting external APIs

## Pattern 5: Git Repository — Versioned Agent Configuration

### When to Use

- Managing production agents across a team
- Need change history, rollback capability, peer review for prompt changes
- Regulatory/compliance requirement for audit trail of agent behavior changes

### How It Works

Maintain a Git repository with agent configurations:

```
agents/
  alert-triage/
    README.md          # Purpose, owner, version
    system-prompt.md   # The agent's system prompt
    steps.yaml         # Step definitions and configuration
    CHANGELOG.md       # Version history
  vuln-reporter/
    ...
knowledge-store/
  playbooks/
  compliance-frameworks/
```

When making changes: update in Git → review via PR → apply to Kindo manually.

→ See [Prompt and Agent Configuration Management](/best-practices/prompt-and-agent-configuration/) for full versioning and governance guidance.

### Limitations

- **Manual sync:** No Git → Kindo auto-deploy pipeline
- **Recreation required:** Agent configuration must be recreated in the Kindo UI after Git changes

### Customer Evidence

A customer managing 6 production agents maintains a GitHub repository with versioned prompts, changelogs, and a meta-agent that updates the repo README — proving this pattern works at scale.

## Choosing a Pattern

| Question                                                       | Pattern                          |
| -------------------------------------------------------------- | -------------------------------- |
| Agent needs static reference data?                             | Knowledge Store                  |
| Need intermediate results within one run?                      | Sandbox                          |
| Same user runs the agent repeatedly and needs files to stick?  | Persistent Sandbox               |
| Multiple users need to share state across runs?                | External System                  |
| Need team-wide agent config management?                        | Git Repository                   |
| Multiple agents share state?                                   | External System                  |
| Compliance requires audit trail?                               | Git Repository + External System |

## Limitations

Kindo's built-in persistent memory is the per-user, per-agent Persistent Sandbox described above. It does not provide a team-shared persistent memory store that agents can write to and read from across users; the patterns above (External Systems, Git Repository) cover that case.

Kindo does not support programmatic Knowledge Store updates via API. File uploads are manual through the UI.

---

## 'Multi-Agent Coordination Patterns'

Source: https://docs.kindo.ai/best-practices/multi-agent-coordination/

Complex security operations often require multiple specialized agents working together. Kindo supports two broad styles of coordination: direct subagent invocation (a parent agent calls another agent as a tool, in-process) and indirect coordination through external systems and triggers. This guide covers proven patterns for both, with guidance on when each fits.

## Why Multiple Agents?

Not every task needs multiple agents. Use multiple agents when:

- **Different permission levels** — Investigation vs. remediation require different access
- **Human approval gates** — Separate analysis from action with human review
- **Team boundaries** — Different teams own different parts of the process
- **Schedule differences** — Continuous monitoring vs. weekly reporting
- **Separation of concerns** — Simpler, more testable individual agents

A single multi-step agent is simpler and preferred when all steps can run with the same permissions, at the same time, without human review.

## Pattern 1: Trigger Chaining via Ticketing System

### How It Works

Agent A writes a result to a ticketing system (Jira, ServiceNow) → Agent B triggers on that ticket event.

### Architecture

```
[Agent A: Investigate]           [External System]           [Agent B: Remediate]
  Trigger: SIEM alert     →     Creates Jira ticket    →    Triggers on ticket
  LLM: Analyze finding          with structured findings     assignment to "AutoRemediate"
  API Action: Create ticket      in a JSON custom field      LLM: Parse findings
                                                              API Action: Execute fix
                                                              API Action: Update ticket
```

### Step-by-Step Setup

**Agent A (Investigate):**

1. Create a triggered agent monitoring SIEM integration
2. Add LLM step: analyze the alert, classify severity, identify affected systems
3. Add API Action step: create Jira ticket with findings as structured JSON
4. Set ticket assignee to a sentinel value (e.g., "auto-remediate-queue")

**Agent B (Remediate):**

1. Create a triggered agent monitoring Jira
2. Set trigger condition: Assignee = "auto-remediate-queue" AND Priority = "Critical"
3. Add LLM step: parse the JSON findings from Agent A, determine remediation steps
4. Add API Action steps: execute remediation (isolate host, rotate credential, etc.)
5. Add API Action step: update the Jira ticket with remediation report

**Optional: Human Approval Gate:**

1. Agent A creates ticket assigned to a human reviewer
2. Human reviews findings, changes assignee to "auto-remediate-queue"
3. Agent B triggers only after human approval

### Pros

- Full audit trail in the ticketing system
- Human approval naturally fits between agents
- Each agent is independently testable
- Works with any ticketing integration

### Cons

- Latency: depends on ticketing system webhook delivery
- Coupling: agents are coupled through ticket field conventions

## Pattern 2: Direct Webhook Chaining

### How It Works

Agent A makes an API Action call to Agent B's direct webhook URL.

### Step-by-Step Setup

1. **Create Agent B** as a Triggered agent with a [Direct Webhook URL trigger](/features/creating-agents/#direct-webhook-url-triggers)
   - Save the trigger to mint a webhook URL, then copy it
   - Optionally set a natural-language Run Condition to gate when Agent B actually fires
2. **Create Agent A** as any agent type
   - Final API Action step: POST to Agent B's webhook URL
   - Include the structured output from Agent A's analysis in the POST body — Agent B receives it as the trigger payload
3. Agent B evaluates the Run Condition (if set) and fires when satisfied

### Pros

- Fastest coordination pattern (no external system delay)
- No external system dependency
- Simple to set up

### Cons

- No built-in approval gate (fully automated)
- No persistent record of the handoff (unless agents write logs)
- Webhook tokens must be managed securely

### When to Use

- Fully automated pipelines where speed matters
- Internal agent coordination that doesn't need human oversight
- Chaining lightweight processing stages

## Pattern 3: Shared External State

### How It Works

Multiple agents read from and write to the same external system (Notion database, Google Sheet, Confluence page) on independent schedules.

### Example: Security Posture Dashboard

- **Agent 1 (Vuln Scanner):** Scheduled daily, writes vulnerability counts to Notion
- **Agent 2 (Compliance Checker):** Scheduled weekly, writes compliance status to same Notion DB
- **Agent 3 (Posture Report):** Scheduled monthly, reads all data, generates executive summary

### Setup

1. Create a shared Notion database (or Google Sheet) with defined columns
2. Each agent uses API Actions to read/write its designated columns
3. Use timestamps and agent IDs to track provenance

### Pros

- Agents are fully decoupled (don't know about each other)
- Easy to add new agents to the ecosystem
- Persistent, human-readable state

### Cons

- No real-time coordination (schedule-dependent)
- Potential race conditions if agents write concurrently
- Requires consistent data format conventions

## Pattern 4: Manual Handoff with Structured Output

### How It Works

Agent A produces structured output → human copies it → human provides it as input to Agent B.

### When This Is The Right Choice

- Regulatory requirement for human review before action
- Low-volume processes (incident-level, not alert-level)
- Initial deployment before automating the handoff

### How to Set It Up

1. Agent A: ensure final LLM step outputs well-structured JSON or markdown
2. Agent B: define an agent input that accepts the output format from Agent A
3. Human: run Agent A → review output → run Agent B with output as input

### Transitioning to Automation

- Start with manual handoff to validate the process
- Once confident in Agent A's output quality, switch to Pattern 1 or 2

## Pattern 5: Subagent Invocation

### How It Works

The parent agent calls another agent as a tool from within its own run. The subagent executes as a separate agent run linked back to the parent — no external trigger, ticket, or webhook is involved, and the parent decides at run time which subagent (if any) to invoke and what to pass it.

To make an agent invokable this way, open its agent builder and turn on **Available as subagent** in the configuration panel.

### Who Can Toggle or Invoke a Subagent

One access model gates both flipping the toggle on an agent and invoking it as a subagent from a parent agent. You need **Owner** access on the agent. You have Owner access if any of the following is true:

- You created the agent
- You have been granted **Owner** access on the agent (directly, or via a user group)
- The agent's organization-level role is set to **Owner** and you are in the same organization
- You are an organization admin in the agent's organization

This means an agent built by one teammate can be exposed and invoked as a subagent by another teammate as long as the second teammate has Owner access. Authorship and ownership are tracked separately — being granted ownership is sufficient.

There is one additional restriction on the agent itself: the toggle cannot be enabled on an agent that has an event or direct-webhook trigger. A scheduled/cron trigger is fine, as is no trigger at all. Agents that react to external events should be exposed via their trigger, as in Pattern 2.

### Architecture

```
[Parent Agent]                                  [Subagent: Investigate]
  LLM: triage SIEM alert                  →     Triggered as a tool call
  → calls investigate_alert(                    Runs as a separate agent run
      hostname: "web-04")                       linked to the parent run
                                                LLM: deep-dive investigation
                                                API Actions: query Splunk, etc.
                                                Returns findings to the parent
```

### Passing Data to a Subagent

- **Declared inputs** — Inputs defined on the subagent become typed parameters the parent agent fills in when invoking it.
- **Freeform context** — The parent agent can also forward a block of freeform text (up to 32,000 characters) alongside the declared inputs, to share any context or inputs it deems appropriate.

### Step-by-Step Setup

**Subagent (callee):**

1. Build the agent as you would any single-agent setup.
2. Open the configuration panel and enable **Available as subagent**.
3. (Optional) Declare typed inputs for data the parent should pass as structured arguments.

**Parent Agent (caller):**

1. Build the agent as you would any single-agent setup.
2. Eligible subagents — agents marked **Available as subagent**, with at least one step, that the user running the parent has **Owner** access to — are automatically discovered and exposed as tools. No manual tool configuration is needed.
3. For better performance, include explicit instructions in the parent's system prompt telling the LLM when to call the target subagent and what to pass.

### Audit and Visibility

- Each subagent invocation creates its own run, linked back to the parent run.
- Both the parent and subagent appear in the agent run history with cross-links.
- When the parent forwards freeform context, it is shown in a collapsible card above the child run's first message.

### Pros

- Lowest latency — no external system in the loop
- No ticketing/webhook configuration required
- Audit trail in Kindo (parent run ↔ subagent run linkage)

### Cons

- Both agents run inside the same org and permission scope — not suitable for cross-team boundaries
- No built-in human approval gate (parent decides; subagent runs)

### When to Use

- Investigation/triage handoffs inside a single team
- Setups where you want subagent execution audited in Kindo, not in an external ticketing system

## Choosing a Pattern

| Need                                     | Pattern                                                    |
| ---------------------------------------- | ---------------------------------------------------------- |
| Human approval between agents            | Trigger Chaining (with approval gate) or Manual Handoff    |
| Fastest automated handoff                | Subagent Invocation or Direct Webhook                      |
| Agents run on different schedules        | Shared External State                                      |
| Full audit trail                         | Trigger Chaining (ticketing system) or Subagent Invocation |
| Simplest setup                           | Manual Handoff or Subagent Invocation                      |
| Maximum decoupling / cross-team boundary | Shared External State                                      |

## Design Principles for Multi-Agent Systems

1. **Start with one agent, split when needed.** Don't over-architect. Begin with a single multi-step agent and only split into multiple agents when you have clear separation requirements (permissions, schedules, teams).

2. **Use structured output formats.** JSON with a defined schema is the lingua franca between agents. Include version fields so you can evolve the format over time.

3. **Make each agent independently testable.** You should be able to run Agent B with mock input without needing Agent A. This makes debugging and iteration much faster.

4. **Log everything.** Each agent should record what it received, what it decided, and what it did — in the ticketing system or external store, not just in Kindo Terminal.

5. **Plan for failure.** What happens if Agent B fails? Design agents to be idempotent when possible (running twice produces the same result as running once).

## Limitations

Kindo does not provide a built-in orchestration layer for fan-out, retries, or scheduling across multiple agents. Patterns 1–4 use external systems for that coordination; Pattern 5 keeps the handoff in-process but still leaves orchestration to the parent agent's LLM.

There is no built-in human-approval gate for Pattern 5 — the parent agent's LLM decides when to invoke a subagent. If you need a human in the loop between agents, use Pattern 1 with an approval-queue assignee or Pattern 4 (Manual Handoff).

These are architectural constraints of the current platform, not fundamental design decisions.

---

## 'Security Workflow: Scheduled Vulnerability Report'

Source: https://docs.kindo.ai/best-practices/scheduled-vulnerability-report/

This walkthrough shows you how to build a scheduled agent that generates weekly vulnerability prioritization reports. By the end, you'll have an agent that automatically fetches vulnerability data, prioritizes findings, and delivers executive reports.

## Overview

**What this workflow does:**

- Runs automatically on a schedule (weekly cron)
- Fetches vulnerability findings from your scanner
- Prioritizes by CVSS, exploit availability, and asset criticality
- Generates an executive summary with top 10 priorities
- Posts the report to Slack or email

**Who it's for:** Vulnerability management teams, DevSecOps engineers

**What it produces:** Prioritized vulnerability report posted to Slack or email

```
Cron trigger (weekly) -> Fetch vuln data -> Prioritize with LLM -> Generate report -> Post to Slack
```

## What You'll Need

- Kindo account with a vulnerability scanner integration (Tenable, CrowdStrike, or similar)
- Slack integration for report delivery
- ~45 minutes

## The Workflow

### Step 1: Create a Scheduled Agent

:::tip
Cron expressions use the standard format: `minute hour day-of-month month day-of-week`. Use [crontab.guru](https://crontab.guru) to validate your expressions.
:::

### Step 2: Add an API Action Step — Fetch Vulnerability Data

:::note
Large API responses are automatically written to the sandbox. Use sandbox commands to filter and process the data before passing to LLM steps. See [Working with Large Context](/best-practices/working-with-large-context/) for techniques.
:::

### Step 3: Add an LLM Step — Prioritize and Summarize

### Working with Large Scan Results

For scans with 10,000+ findings, use the sandbox:

1. **First LLM pass** — Group findings by severity in the sandbox
2. **Second LLM pass** — Analyze only Critical/High findings
3. **Filter at source** — Use scanner API query parameters to limit results

→ See [Working with Large Context](/best-practices/working-with-large-context/) for detailed sandbox techniques.

### Step 4: Add an API Action Step — Deliver the Report

### Step 5: Test and Enable

## Adapting This Workflow

### Change Scanner

| From        | To          | Changes Needed                                                |
| ----------- | ----------- | ------------------------------------------------------------- |
| Tenable     | CrowdStrike | Update API endpoint, authentication headers, query parameters |
| Tenable     | Qualys      | Change to Qualys API format, adjust severity mappings         |
| CrowdStrike | Rapid7      | Update to InsightVM API, adjust response parsing              |

Same pattern, different API. The LLM prioritization step remains unchanged.

### Change Cadence

| Frequency | Use Case                       | Cron Expression          |
| --------- | ------------------------------ | ------------------------ |
| Daily     | Critical asset monitoring      | `0 9 * * *`              |
| Weekly    | Standard vulnerability reports | `0 9 * * 1`              |
| Monthly   | Executive reviews              | `0 9 1 * *`              |
| Custom    | Compliance deadlines           | Adjust to specific dates |

### Add Compliance Overlay

1. Upload your compliance framework (PCI-DSS, GDPR, SOC 2) to Knowledge Store
2. Add a step that cross-references findings against framework requirements
3. Include compliance mapping in the LLM prompt:
   ```
   Cross-reference each finding with the attached compliance framework.
   Identify which requirements are violated and the potential impact.
   ```
4. Output includes compliance-specific recommendations

## Troubleshooting

### Scanner API Returns No Data

**Symptoms:** API Action step succeeds but returns empty results

**Check:**

- Date range parameters (are you looking at the right time period?)
- Severity filters (are you excluding the findings you want?)
- Authentication (is the API key valid and has permissions?)
- API quotas (have you hit rate limits?)

**Fix:**

- Expand date range to "last 30 days" for testing
- Remove severity filters temporarily to see all findings
- Regenerate API keys if authentication fails
- Add delays between requests if hitting rate limits

### LLM Produces Inconsistent Prioritization

**Symptoms:** Same vulnerability gets different severity ratings on different runs

**Check:**

- Prompt clarity (are criteria well-defined?)
- Model capability (is it a reasoning model?)
- Context completeness (is all necessary data provided?)

**Fix:**

- Add explicit weighting: "Prioritize in this order: 1) CVSS, 2) Exploit availability..."
- Include examples in the prompt: "Critical: CVSS 9.0+ with public exploit..."
- Switch to a more capable model (GPT-4, Claude 3 Opus)
- Add a validation step that checks consistency

### Report Not Delivered

**Symptoms:** Agent runs successfully but report doesn't appear in Slack/email

**Check:**

- Delivery step configuration (correct channel/email?)
- Integration permissions (can the integration post to that channel?)
- Message formatting (is it too long? malformed?)
- Rate limits (has the integration hit API limits?)

**Fix:**

- Verify channel name/email address is correct
- Test the integration manually in the integration settings
- Shorten the message or split into multiple posts
- Add error handling to catch delivery failures
- Check integration logs for specific error messages

## Next Steps

- **[Memory and Persistence Patterns](/best-practices/memory-and-persistence/)** — Learn how to maintain state across agent runs
- **[Multi-Agent Coordination](/best-practices/multi-agent-coordination/)** — Chain multiple agents for investigate → remediate pipelines
- **[On-Demand Threat Hunting](/best-practices/threat-hunting/)** — Build interactive workflows for threat hunting
- **[Working with Large Context](/best-practices/working-with-large-context/)** — Handle large scan results efficiently

---

## 'Security Agent: Automated Alert Triage'

Source: https://docs.kindo.ai/best-practices/security-alert-triage/

This walkthrough shows you how to build a triggered agent that automatically enriches and triages security alerts from your ticketing system. By the end, you'll have an agent that fires when new alerts arrive, analyzes them, and updates tickets with triage reports.

## Overview

**What this agent does:**

- Monitors your ticketing system (Jira/ServiceNow) for new security alerts
- Automatically extracts IOCs and enriches with threat intelligence
- Classifies severity and recommends actions
- Updates the ticket with a structured triage report

**Who it's for:** SOC analysts, security engineers, incident responders

**What it produces:** Enriched tickets with triage reports that help prioritize response

```
Jira ticket created -> Trigger fires -> LLM enriches + classifies -> Comment added with triage report
```

## What You'll Need

- Kindo account with Jira (or ServiceNow) integration configured
- A Jira project where security alerts are filed
- ~30 minutes

## The Agent

### Step 1: Create a Triggered Agent

### Step 2: Add an LLM Step — Enrich and Classify

### Step 3: Add an API Action Step — Update the Ticket

### Step 4: Test with a Sample Alert

## Verification

### Expected Results

| Check                          | Expected Result                                            |
| ------------------------------ | ---------------------------------------------------------- |
| Trigger fires on new ticket    | Agent executes within seconds of ticket creation           |
| LLM produces structured output | JSON with IOCs, classification, severity, recommendation   |
| Ticket updated                 | New comment with triage report visible in Jira             |
| Priority set correctly         | Matches severity classification (Critical/High/Medium/Low) |

### Verification Steps

1. **Check Kindo Terminal** — Review the full execution trace for errors
2. **Check Jira ticket** — Verify comment was added and priority was updated
3. **Review LLM output** — Ensure structured JSON is well-formed and complete
4. **Test edge cases** — Try tickets without CVEs, with multiple CVEs, with different alert types

## Adapting This Agent

### Replace Jira with ServiceNow

1. Change the integration from Jira to ServiceNow
2. Update API Action steps to use ServiceNow MCP tools (`servicenow.add_comment`, etc.)
3. Same pattern, different integration

### Add a Second Agent for Automated Remediation

1. Create Agent B (Remediate) as a triggered agent
2. Set trigger condition: Jira ticket assigned to "auto-remediate" queue
3. Agent B executes fixes and updates ticket
4. See [Multi-Agent Coordination](/best-practices/multi-agent-coordination/) for details

### Add Slack Notification for Critical Alerts

1. Add an API Action step after the LLM classification
2. Use Slack integration to post to a channel
3. Condition: Only post if severity is Critical or High

### Use Different Classification Framework

1. Update the LLM prompt to use MITRE ATT&CK tactics instead of generic categories
2. Map MITRE techniques to your organization's response procedures
3. Include MITRE mapping in the structured output

## Troubleshooting

### Trigger Not Firing

**Symptoms:** Agent doesn't execute when tickets are created

**Check:**

- Integration connection status and active connection (in the Command Center under **Manage Your Integrations**)
- Trigger conditions match ticket fields exactly (case-sensitive)
- Ticket is created in the correct project with correct type
- Webhook delivery in the integration's admin panel (Jira/ServiceNow)

**Fix:**

- Reconnect the integration if connection shows errors
- Adjust trigger conditions to match actual ticket field values
- Test with a manually created ticket matching all conditions

### LLM Output Not Structured

**Symptoms:** Output is narrative text instead of JSON

**Check:**

- Prompt explicitly requests JSON format
- JSON schema is included in the prompt
- Model is capable of structured output (GPT-4, Claude 3, etc.)

**Fix:**

- Add explicit instruction: "Output ONLY valid JSON, no markdown, no explanation"
- Include example JSON structure in the prompt
- Switch to a more capable model if using a lightweight one

### API Action Failing

**Symptoms:** Jira/ServiceNow actions return errors

**Check:**

- MCP server is running (for self-hosted deployments)
- Integration permissions allow the actions (create comment, update issue)
- Issue key format is correct
- API rate limits haven't been exceeded

**Fix:**

- Check MCP server status in deployment logs
- Verify integration OAuth scopes include write permissions
- Test actions manually in the integration first
- Add retry logic for transient failures

---

## 'Security Workflow: On-Demand Threat Hunting'

Source: https://docs.kindo.ai/best-practices/threat-hunting/

This walkthrough shows you how to build a manual workflow for interactive threat hunting. By the end, you'll have a reusable workflow that accepts a hunt hypothesis, queries one or more data sources, pivots on suspicious indicators, and produces a structured hunt report.

## Overview

**What this workflow does:**

- Accepts a hunt hypothesis and search scope as workflow inputs
- Queries a primary data source such as Splunk, Datadog, or another log system
- Uses an LLM to identify suspicious patterns, IOCs, and follow-up pivots
- Runs a second query to validate or expand on those findings
- Produces a structured hunt report with timeline, affected systems, and recommended actions

**Who it's for:** Threat hunters, senior SOC analysts, incident responders

**What it produces:** A repeatable hunt report with findings, IOCs, confidence level, and next actions

```
Manual inputs -> Query logs -> Correlate with LLM -> Pivot on IOCs -> Summarize findings
```

## What You'll Need

- Kindo account with at least one logging or SIEM integration configured
- Access to a dataset worth hunting in (authentication logs, endpoint telemetry, DNS, proxy logs, cloud audit logs, etc.)
- A clear hypothesis to test
- ~45 minutes

:::tip
This pattern works best as a **Workflow** agent, not a triggered agent. Threat hunting is exploratory: you want to enter a hypothesis, inspect the results, adjust the scope, and run again.
:::

## The Workflow

### Step 1: Create a Manual Workflow Agent

### Step 2: Define Workflow Inputs

Workflow inputs make the hunt reusable. Each run can use a different hypothesis and scope without editing the agent.

:::tip
Workflow inputs are the easiest way to turn an investigative playbook into a reusable hunt template. You can keep the workflow logic stable while changing the question you are asking.
:::

### Step 3: Add an API Action Step — Query the Primary Data Source

Start with the system most likely to contain the signal you need.

:::note
For large log datasets, avoid trying to push everything directly into the LLM context. Let the API step retrieve the data, then use the sandbox or a filtering step to narrow it down before final analysis.
:::

### Step 4: Add an LLM Step — Correlate and Extract Leads

Now turn raw log output into a set of concrete leads to investigate.

### Step 5: Add an API Action Step — Pivot on the Most Suspicious Indicators

A good hunt rarely ends with one query. Use the extracted leads to search another source or another log slice.

:::tip
This is where workflow chaining becomes powerful: each step can refine the next one. The first query finds suspicious leads; the second query validates whether those leads actually matter.
:::

### Step 6: Add an LLM Step — Produce the Hunt Report

Use a second LLM step to synthesize the full investigation.

## Running a Hunt

## Working with Large Hunt Data

Threat hunting often produces more data than an LLM should ingest directly.

### Useful Sandbox Patterns

- Use `rg`, `grep`, or lightweight scripts to isolate only the relevant records
- Build small timelines from raw logs before sending them to an LLM step
- Deduplicate repeated events so the model focuses on unique signals
- Split analysis by source (identity, endpoint, network) before writing the final summary

For more techniques, see **[Working with Large Context](/best-practices/working-with-large-context/)**.

## Adapting This Workflow

### Add More Data Sources

Start with one log source, then expand:

| First source | Possible pivot source |
| --- | --- |
| Identity logs | Endpoint telemetry |
| SIEM alerts | DNS or proxy logs |
| Cloud audit logs | IAM change history |
| EDR telemetry | Network flow logs |

### Save Reusable Hunt Templates

Keep a library of hypotheses such as:

- Suspicious OAuth consent grants
- Impossible travel or unusual geo-authentication
- Lateral movement after VPN login
- New admin role assignments in cloud environments
- Beaconing to suspicious external infrastructure

You can store these in internal documentation or another system your team already uses.

### Chain into Follow-On Workflows

After the hunt completes, you can:

- Trigger a triage or remediation workflow
- Create a ticket with the findings
- Send the final report to a security operations channel
- Hand off to another agent for containment or evidence collection

See **[Multi-Agent Coordination](/best-practices/multi-agent-coordination/)** for patterns that connect investigations to downstream automation.

## Troubleshooting

### Query Returns Too Much Data

**Symptoms:** The first API step succeeds, but the output is too large or noisy to use.

**Fix:**

- Narrow `time_window`
- Limit `scope` to a smaller set of users, hosts, or services
- Filter for event types relevant to the hypothesis
- Use sandbox tools to reduce the dataset before LLM analysis

### LLM Suggests Weak or Obvious Pivots

**Symptoms:** The correlation step produces generic recommendations instead of useful next queries.

**Fix:**

- Make the hypothesis more specific
- Include clearer instructions about the types of signals you care about
- Ask for prioritized pivots, not a long brainstorm list
- Provide a small example of the output shape you want

### Final Report Sounds More Certain Than the Evidence Supports

**Symptoms:** The report states conclusions as facts even though the data is ambiguous.

**Fix:**

- Instruct the LLM to separate confirmed findings from inference
- Require an explicit confidence level with reasoning
- Ask it to list missing evidence or validation steps
- Review the intermediate outputs before sharing the final report

## Next Steps

- **[Security Workflow: Automated Alert Triage](/best-practices/security-alert-triage/)** — Convert recurring alerts into structured triage reports
- **[Security Workflow: Scheduled Vulnerability Report](/best-practices/scheduled-vulnerability-report/)** — Build a recurring reporting workflow for vulnerability data
- **[Working with Large Context](/best-practices/working-with-large-context/)** — Learn how to handle large log volumes safely
- **[Multi-Agent Coordination](/best-practices/multi-agent-coordination/)** — Chain hunts into response and remediation workflows

---

## Start Here

Source: https://docs.kindo.ai/start/

Kindo is an AI-powered platform for enterprise security and governance. Whether you're evaluating, deploying, or administering Kindo, this section helps you get oriented quickly.

## What You'll Find Here

## Choose Your Path

- **Evaluating Kindo?** Start with [What is Kindo?](/start/what-is-kindo/) then try a [Quickstart](/quickstarts/).
- **Installing on-prem?** Jump to [Deploy and Operate](/deploy/) for infrastructure requirements and installation guides.
- **Administering?** Head to [Admin and Security](/admin/) for SSO, RBAC, and governance setup.
- **Integrating via API?** See [API Overview](/overview/getting-started/) for authentication, models, and per-API quickstarts.

---

## What is Kindo?

Source: https://docs.kindo.ai/start/what-is-kindo/

Kindo is the AI-native automation platform built for technical operations. We equip SecOps, DevOps, and ITOps teams with intelligent agents that move beyond alerts and summaries into real, autonomous execution.

With Kindo, operators don't just detect problems — they resolve them through policy-aware, human-in-the-loop agents that can remediate vulnerabilities, enforce IAM policies, trace incidents, and harden cloud environments.

At the core is **Deep Hat**, Kindo's proprietary LLM tuned for real infrastructure and threat behavior. Agents execute tasks based on operator intent, not rigid playbooks, and adapt in real time as conditions change.

## Key Capabilities

- **AI Chat** — Secure conversational AI with enterprise controls
- **Agents** — Build and deploy autonomous AI agents for SecOps, DevOps, and ITOps workflows
- **Integrations** — Universal MCP connectors let agents read and write across your stack
- **Governance** — Fine-grained policies, DLP filters, and compliance controls
- **Observability** — Full visibility into AI usage, audit logs, and metrics

## Deployment Models

Kindo is available in two deployment models:

### SaaS (Cloud-Hosted)

The fastest way to get started. Kindo manages infrastructure, updates, and availability.

### Self-Hosted (On-Prem)

Deploy Kindo in your own infrastructure for maximum control over data residency and network isolation.

## Feature Comparison

| Feature | SaaS | Self-Managed |
|---------|------|--------------|
| Chat | ✅ | ✅ |
| Agents | ✅ | ✅ |
| Integrations | ✅ | ✅ |
| Model RBAC | ✅ | ✅ |
| User Groups | ✅ | ✅ |
| Self-Managed Models | ✅ | ✅ |
| Enterprise IDP Support | ✅ | ✅ |
| DLP Filters | ✅ | ✅ |
| Audit Log | ✅ | ✅ |
| Secrets Manager Integration | ✅ | ✅ |
| Metrics Integration | — | ✅ |
| Audit Log Isolation | — | ✅ |
| Customizable Deployment | — | ✅ |
| Customizable Secrets Manager | — | ✅ |

## Who Uses Kindo?

**Kindo Users** are technical professionals in DevOps, SecOps, and ITOps who communicate with LLMs, create and manage agents that automate workflows, and integrate via APIs.

**Kindo Administrators** manage governance, security, and compliance — controlling user and group access to models, integrations, and agents, enforcing DLP filters, and managing secrets managers.

| Role | Primary Use |
|------|-------------|
| **End Users** | AI Chat, Agents |
| **Admins** | SSO, RBAC, Policy management, DLP |
| **Operators** | Deployment, Monitoring, Upgrades |
| **Developers** | API integration, Custom agents |

## Next Steps

---

## Concepts and Terminology

Source: https://docs.kindo.ai/start/concepts/

This glossary covers the core concepts and terminology used when working with the Kindo platform.

## AI Models

### Generative AI Model

A broad term for any ML model that the Kindo platform supports. While Kindo functionality is primarily driven by LLMs, the platform also supports other model types.

### Embeddings Models

Models that tokenize content into numeric vectors representing semantic meaning. Used for knowledge retrieval across files and large contexts.

### Multi-modal Models

Models that work with multiple content types such as text, audio, images, and video. Models are typically constrained to a few content types.

### Large Language Model (LLM)

The fundamental AI model used in requests. Examples include OpenAI o1, Anthropic Claude, and DeepSeek R1.

LLMs used within Kindo are one of two types:

- **Worker LLM** -- The LLM used within Kindo for internal, non-user operations.
- **User LLM** -- The LLM that users or agents make requests to. Within Kindo's user interface these are referred to as "Models."

### Self-Managed Model

A generative AI model that an administrator manages and configures for Kindo's use. This may include self-hosted models or cloud deployments such as Anthropic models via AWS Bedrock in GovCloud.

## Platform Concepts

### Kindo Terminal

The primary user interface within Kindo. At the Terminal, a user makes requests to a User LLM, either directly through a Chat or through an Agent Run.

### Chat

A collection of requests from a user to User LLMs through the Kindo Terminal *without* an Agent. Chats are divided by Memory, enabling the user to communicate with different models across different historical contexts.

### Agent

A Kindo-managed automation that executes a series of steps or sequential, atomic operations. There are three types:

- **Chatbots** -- Agents designed to respond to users with information gathered from an AI model and a knowledge base.
- **Workflow Agents** -- Agents that conduct a set of operations within a system of record, including API calls and external tool invocations.
- **Triggered Agents** -- Workflow agents that lie dormant until a specified event occurs (such as a new ticketing system entry), then launch a response.

### Memory

The historical collection of LLM responses from user requests. Memory enables users to mix and match User LLM responses and leverage output from previous interactions. Chats and all types of Agents hold memory.

### Run

An instance of interaction between a user and a User LLM brokered by Kindo. Runs result from communications through Chats, Agents, Triggered Agents, and Public API calls.

- **Agent Run** -- The final output of the last LLM Step.
- **Step Run** -- The individual response of a single LLM Step within an Agent.

### Kindo API

The set of REST API endpoints exposed by Kindo:

- **Inference API** -- An individual request to a User LLM with no memory.
- **Agent API** -- A call that produces the output of an Agent Run.

### Target

The output location of an Agent Run or Step Run. Targets typically refer to the Kindo Terminal but can also refer to external systems like ticketing platforms or APIs.

### Resource

A structured data entity provided by an Integration. Examples include Tickets, Users, Emails, Logs, and Metrics.

### File

A file within the Kindo Platform. Files can be uploaded by users, provided by Integrations, or generated by AI Models.

### Secret

A sensitive text blob consumed on the Kindo Platform, typically representing API keys, access tokens, or environment variables. Secrets are stored in the **Secrets Vault**.

## Infrastructure Terminology

### Integration

A system external to Kindo that connects to enable data ingestion and outbound actions. For example, the Linear ticketing system provides Resources to Kindo and enables actions like adding comments to tickets.

## Product Offerings

### Kindo SaaS

The cloud-hosted version of Kindo, managed by the Kindo team.

### Self-Managed Kindo

The version deployed by administrators into an environment they control, such as a public cloud, hybrid cloud, or on-premises infrastructure.

---

## Use Cases

Source: https://docs.kindo.ai/start/use-cases/

Kindo is an enterprise platform that professionals in DevOps, SecOps, and ITOps use to create autonomous infrastructure -- infrastructure that helps manage and secure itself using natural language instructions. Kindo agents are typically deployed across three categories of use cases.

## Getting Started by Role

Choose your role to see relevant workflows and guides:

| I am a...                 | Start here                                                                                                                                                                                                |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **SOC Analyst**           | [Build Your First Workflow](/quickstarts/build-first-workflow/) → [Alert Triage](/best-practices/security-alert-triage/) → [Threat Hunting](/best-practices/threat-hunting/)                              |
| **Vulnerability Manager** | [Build Your First Workflow](/quickstarts/build-first-workflow/) → [Vulnerability Reporting](/best-practices/scheduled-vulnerability-report/) → [Memory Patterns](/best-practices/memory-and-persistence/) |
| **DevSecOps Engineer**    | [Build Your First Workflow](/quickstarts/build-first-workflow/) → [Multi-Agent Coordination](/best-practices/multi-agent-coordination/) → [Integrations](/features/integrations/)                         |
| **Platform Engineer**     | [Build Your First Workflow](/quickstarts/build-first-workflow/) → [API Overview](/overview/getting-started/) → [Deploy Guides](/deploy/)                                                                    |
| **IT Operations**         | [First Chat](/quickstarts/first-chat/) → [Create Your First Agent](/quickstarts/first-agent/) → [Integrations](/features/integrations/)                                                                   |

## Incident Response

Incident Response refers to use cases where Kindo agents serve as first responders to changes in the security, reliability, or uptime of infrastructure.

### Security Incident Response

For Enterprise Security teams, these use cases typically fall under Managed Detection and Response (MDR) or Incident Detection and Response (IDR). Examples include:

- Analyzing threat intelligence feeds against failed login alerts in a SIEM to identify potential attacker C2 infrastructure.
- Querying logging infrastructure to determine exposure from compromised credentials across databases and secrets management systems.
- Reviewing indicators of compromise against threat intelligence and correlating with root cause analysis to determine evidence of malicious activity.

### DevOps / Platform Engineering Incident Response

For DevOps and Platform Engineering teams, Incident Response typically involves Root Cause Analysis (RCA) of outages, service interruptions, or quality of service changes. Examples include:

- Analyzing logging infrastructure and observability suites for activity preceding an outage, then performing RCA using system configuration context.
- Analyzing firewall configs, load balancer settings, and routing logs to determine causes of network performance degradation.
- Cross-referencing internal analysis with outage maps from telcos and cloud providers to identify macro system failures.

## Vulnerability and Compliance Enforcement

Kindo agents proactively review systems for faults, vulnerabilities, and change management issues to prevent incidents before they occur.

### Security Vulnerability and Compliance

For Enterprise Security teams, this involves continually reviewing system changes and IAM infrastructure for exploitable vulnerabilities or compliance violations. Examples include:

- Reviewing IAM policies against GDPR guidelines to verify least privilege is maintained per GRC requirements.
- Scanning public-facing infrastructure for exposed services, cross-referencing versions with known CVEs, and generating proof-of-concept exploits for critical findings.

### DevOps / Platform Engineering Compliance

For DevOps and Platform Engineering teams, this involves reviewing change management procedures and infrastructure changes for potential faults. Examples include:

- Reviewing system or IAM profile changes to determine if they may cause instability, and reporting results via email.
- Cross-referencing Infrastructure as Code changes with PCI-DSS compliance requirements.

## ITOps Automation

ITOps Automation use cases focus on removing time-consuming service offering tasks from ITOps professionals. Examples include:

- Providing a helpdesk chatbot for answering questions about IT policies and filing tickets.
- Automatically provisioning development environments for new users when tickets are created.

---

## Quickstarts

Source: https://docs.kindo.ai/quickstarts/

Get hands-on with Kindo through guided, end-to-end walkthroughs. Each quickstart is designed to get you from zero to "it worked" as fast as possible.

## Available Quickstarts

---

## Getting Started with Kindo

Source: https://docs.kindo.ai/quickstarts/getting-started/

Kindo enables professionals on SecOps, DevOps, and platform engineering teams to automate challenging and tedious tasks from their playbooks and runbooks using AI agents. This guide walks you through signing in and navigating the interface.

## Signing In

## The Terminal

After signing in, you arrive at the Terminal window with the query box at the bottom. This is the default screen and the primary workspace for interacting with AI models.

![The Kindo Terminal showing the main work area, Chat/Agents selector, model selector, query bar, and icon bar](../../../assets/docs/getting-started/terminal-overview.png)

From here you can:
- Select an AI model and run queries as a **Chat**
- Navigate to the **Agents** tab to manage and execute agents

## Chat Window

### Selecting a Model

Above the query bar is a model selector where you can choose from available LLMs. Models are organized into categories:

- **General Purpose** -- Versatile models for most tasks
- **Longer Context** -- Models optimized for large inputs
- **Reasoning** -- Models specialized in complex analysis
- **Cybersecurity Focused** -- Models tuned for security operations

### Running a Query

Type a question in natural language in the query bar and press **Enter**. The response appears in the main work area.

### Attaching Files

Click the **+** button to attach files to your query. Once files are attached, you can:

![Attaching files to a chat query](../../../assets/docs/getting-started/attach-files.png)

- Remove files using the **Files** panel
- When multiple files are attached, use **For All Files** to apply a condition collectively or to each file independently

### Tools

Tools are how you connect to your various sources of information. Kindo can connect to virtually any system of record that you need — from security platforms like CrowdStrike and SentinelOne to collaboration tools like Jira, Slack, and GitHub.

![The Tool Policies panel showing available tool servers and their connection status](../../../assets/docs/getting-started/tools-selection.png)

Use the **Tool Policies** panel to browse, search, and manage your connected tool servers. Each tool server can be set to **Active**, **Off**, or **Connect** for first-time setup.

### Work History

Use the history panel to:

- **History** -- Review queries from the last 5 days, filtered by your own or shared queries
- **Agents Run** -- Review agent executions, filtered by type (Chatbot, Workflow, Triggered)

## Agents Window

The Agents screen lets you create, edit, and deploy AI agents that automate repeatable operations.

![The Agents screen showing available agents with edit, run, share, and delete options](../../../assets/docs/getting-started/agents-screen.png)

### My Agents

View all your agents filtered by type:

- **All Agents** -- Every available agent
- **Chatbots** -- Query-based agents
- **Workflow Agents** -- Process automation agents
- **Triggered Agents** -- Event-driven agents

Each agent can be shared, deleted, edited, or run directly from this screen.

### Creating an Agent

Select **Create an Agent** to build a new agent. Choose from three types:

![Agent type selection showing Triggered, Workflow, and Chatbot options with Build Agent buttons](../../../assets/docs/getting-started/agent-type-selection.png)

- **Triggered** -- Reacts to events in integrated systems
- **Workflow** -- Executes a defined sequence of operations
- **Chatbot** -- Responds to user queries using knowledge bases

The Agent Configuration panel lets you describe what you want using natural language:

![The Workflow Agent Configuration panel with Name, Description, Instructions, and Knowledge Store fields](../../../assets/docs/getting-started/workflow-agent-config.png)

For detailed agent creation instructions, see [Creating Agents](/features/creating-agents/).

## Settings

Access settings via the gear icon in the top right:

- [**Models**](https://app.kindo.ai/?settings=models) -- View and manage available LLMs
- **Integrations** -- Connect to third-party applications
- [**Model Access & DLP**](https://app.kindo.ai/?settings=model-access-and-dlp) -- Manage access controls and DLP
- [**API**](https://app.kindo.ai/?settings=api) -- View API keys and available models
- [**Secrets Vault**](https://app.kindo.ai/?settings=secrets-vault) -- Manage stored secrets

## Next Steps

- [Create your first agent](/features/creating-agents/) to automate a workflow
- [Configure integrations](/features/integrations/) to connect your existing tools
- [Set up security controls](/admin/security-controls/) to manage access and DLP

---

## 'First Chat Experience'

Source: https://docs.kindo.ai/quickstarts/first-chat/

This quickstart walks you through your first AI-powered conversation in Kindo. By the end, you will have selected a model, sent a query, and used tools to enhance your results.

## Prerequisites

- A Kindo account (SaaS or self-hosted)
- Signed in to the Kindo Terminal (see [Getting Started](/quickstarts/getting-started/))

## Start a Conversation

## Attach Files

You can provide additional context by attaching files to your query:

File attachments are useful for tasks like analyzing log files, reviewing configurations, or summarizing documents.

## Use Tools

Tools connect Kindo to your systems of record, extending what the model can access beyond its training data. Kindo supports a wide range of tool servers — from security platforms like CrowdStrike and SentinelOne to collaboration tools like Jira, Slack, and GitHub.

Use the **Tool Policies** panel to browse and manage available tool servers. Each tool server can be toggled to **Active**, **Off**, or **Connect** for first-time setup. Active tools are automatically available to the model during your conversation.

Some integrations also let you select a connection. The active connection is used in chats and in agents configured to use the runner's active connection. Turning the integration **Off** removes its tools from the chat.

To change an active connection, open **Command Center** > **Manage Your Integrations**, expand the integration, and select a connection in the expanded connections table. The table shows each connection's read-only connection handle beside its connection label, which helps distinguish connections with similar names.

## Tips

- **Be specific** -- The more context you provide, the better the response. Include relevant details about your environment, constraints, and desired format.
- **Iterate** -- Follow up with clarifying questions. Kindo maintains conversation context across messages.
- **Try different models** -- Switch between General Purpose, Reasoning, and Cybersecurity models to compare results for different tasks.

## Next Steps

- [Create Your First Agent](/quickstarts/first-agent/) to automate a recurring task
- [Get Started with the Kindo API](/overview/getting-started/) to interact with Kindo programmatically
- [Learn about Agents](/features/agents/) to understand Kindo's automation framework

---

## 'Create Your First Agent'

Source: https://docs.kindo.ai/quickstarts/first-agent/

This quickstart walks you through creating a simple workflow agent in Kindo. By the end, you will have a working agent that can be run on demand.

## Prerequisites

- A Kindo account (SaaS or self-hosted)
- Signed in to the Kindo Terminal (see [Getting Started](/quickstarts/getting-started/))

## Create a Workflow Agent

## Run the Agent

## Agent Types

Kindo supports four agent types:

| Type                | Trigger        | Use Case                             |
| ------------------- | -------------- | ------------------------------------ |
| **Chatbot**         | User message   | Knowledge base Q&A, helpdesk         |
| **Manual Workflow** | Manual run     | Runbook execution, report generation |
| **Scheduled**       | Cron schedule  | Recurring reports, periodic checks   |
| **Triggered**       | External event | Incident response, alert triage      |

**Note:** Scheduled agents are workflow agents with a cron trigger. The platform distinguishes them because they have different configuration requirements (schedule expression, timezone) and run patterns.

For this quickstart we used a Manual Workflow agent. To learn about all agent types and advanced configuration, see [Agents](/features/agents/) and [Creating Agents](/features/creating-agents/).

## Next Steps

- **[Build Your First Multi-Step Workflow](/quickstarts/build-first-workflow/)** — Create a realistic workflow with API calls, LLM analysis, and dynamic inputs
- [Get Started with the Kindo API](/overview/getting-started/) to interact with Kindo programmatically
- [Configure Integrations](/features/integrations/) to connect agents to external tools
- [Learn about Creating Agents](/features/creating-agents/) for advanced agent configuration

---

## 'Build Your First Workflow'

Source: https://docs.kindo.ai/quickstarts/build-first-workflow/

This tutorial walks you through building a realistic multi-step workflow that solves a real security problem. By the end, you'll have a working agent that enriches security alerts with threat intelligence and produces structured triage reports.

**What you'll build:** A manual workflow agent that takes a security alert description, enriches it with CVE data from the National Vulnerability Database (NVD), classifies severity, and outputs a triage report.

**Expected time:** ~45 minutes

## Prerequisites

- Kindo account (SaaS or self-hosted)
- Completed [Create Your First Agent](/quickstarts/first-agent/) quickstart
- No external accounts needed (uses public NVD API)

## What You'll Build

```
Input (alert) -> API Action (NVD lookup) -> LLM (classify + triage) -> Output (report)
```

## Step 1: Create a Manual Workflow Agent

## Step 2: Define a Workflow Input

Workflow inputs let you pass dynamic values into your agent when it runs. These become template variables you can reference in prompts.

:::tip
For triggered agents, the trigger event data (like ticket fields) automatically becomes available as template variables. You don't need to define workflow inputs manually — the integration provides them.
:::

## Step 3: Add an API Action Step — Fetch CVE Data

Now add a step that enriches the alert with threat intelligence from the National Vulnerability Database (NVD).

:::note
The NVD API is free, public, and requires no authentication. It's rate-limited to 5 requests per 30 seconds. For production use with high volumes, consider caching or using a commercial threat intelligence feed.
:::

## Step 4: Add an LLM Step — Analyze and Classify

Now add an LLM step that analyzes the enriched alert and produces a triage report.

:::tip
Template variables like `{{alert_description}}` are resolved at runtime from workflow inputs (for manual workflows) or trigger event data (for triggered workflows). You can also reference previous step outputs using `{{step_name.output}}` syntax.
:::

## Step 5: Run and Verify

Test your agent with a realistic security alert.

### Verification Checklist

| Check                        | Expected Result                        |
| ---------------------------- | -------------------------------------- |
| Agent runs without errors    | No red error messages in Terminal      |
| API step executes            | NVD API call returns CVE data          |
| LLM step produces output     | Structured triage report generated     |
| Output contains all sections | IOCs, Classification, Severity, Action |
| Severity makes sense         | Critical/High for CVE-2024-3094        |

## Step 6: Iterate and Improve

Now that you have a working agent, refine it based on the output quality.

## What You Learned

In this tutorial, you built a realistic multi-step workflow and learned:

- **Workflow inputs** — How to define dynamic inputs that become template variables
- **API Action steps** — How to fetch external data (threat intelligence) via REST APIs
- **LLM steps** — How to analyze data and produce structured outputs
- **Multi-step data flow** — How output from one step becomes input to the next
- **Testing and iteration** — How to verify your agent works and refine it

## Next Steps

- **[Add a Trigger](/features/creating-agents/)** — Convert this to a triggered agent that fires automatically when alerts arrive
- **[Configure Integrations](/features/integrations/)** — Connect Jira or ServiceNow to create tickets from triage results
- **[Explore Security Workflows](/best-practices/security-alert-triage/)** — See advanced patterns for alert triage, vulnerability reporting, and threat hunting
- **[Learn Multi-Agent Coordination](/best-practices/multi-agent-coordination/)** — Chain multiple agents together for investigate -> remediate pipelines

---

## 'Use Memory'

Source: https://docs.kindo.ai/quickstarts/memory/

[Memory](/features/memory/) lets Kindo carry useful context across conversations, so you do not have to repeat yourself in every chat. This quickstart walks through the key tasks.

## Prerequisites

- A Kindo account, signed in.
- Memory turned on for your organization (it is on by default). If the **Memory** toggle does not appear in your chat settings menu, an administrator has turned it off — see [Troubleshooting](/features/memory/#troubleshooting).

## Turn Memory On or Off

Memory in chats is controlled by a per-user toggle. It applies to all of your chats — direct conversations with a model.

![Chat settings menu — the Memory toggle under User Memory](../../../assets/docs/memory/chat-memory-toggle.png)

The setting persists across sessions and affects only you. Turning Memory off does not delete anything already stored.

## Ask Kindo to Remember Something

{/* SCREENSHOT SLOT: memory-store-tool-call — A chat conversation in which the user asked Kindo to remember a fact and the assistant's memory_store tool call is visible in the conversation. Caption: "Saving a fact — the memory_store tool call is visible in the conversation." */}

:::note[Duplicate detection]
If a near-identical memory already exists, the assistant reports the duplicate instead of saving a second copy. Review the existing memory on the User Memory page and edit it there if needed.
:::

There is no manual "create memory" form. Everything stored comes from your conversations — to add a fact, ask the assistant to remember it.

## Ask Kindo to Forget Something

:::note
If several stored memories could match, delete the right one yourself from the User Memory page instead. A conversation that already recalled the memory keeps its existing context — the deletion takes effect for later conversations.
:::

## Review, Edit, or Delete Your Memories

Every memory Kindo stores for you is visible on the User Memory page — no other user can see or search it.

![User Memory page — review, edit, or delete stored memories](../../../assets/docs/memory/user-memory-page.png)

## Verify Recall Works

Recall is relevance-based: Kindo searches your stored memories and provides the ones related to the current topic, not all of them.

## Why the Toggle Is Greyed Out with an Agent

In an agent conversation, the Memory toggle in the chat settings menu is disabled. This is expected: your User Memory applies only in chats. Each conversation uses exactly one memory space — a chat uses your User Memory; an agent conversation uses that agent's own [Agent Memory](/features/memory/#agent-memory) (when enabled), never yours. Nothing from your private User Memory is read or written while you work with an agent.

## What to Expect from Agent Memory

Agent Memory is scoped to an agent rather than to you, and it is shared: a fact captured while one person works with the agent can be recalled when a different person uses the agent later.

Because that crosses the usual boundary between users' sessions, it is consent-gated — it stays off unless both the organization administrator and the agent's author explicitly opt the agent in.

When it is on, the chat settings menu shows an added read-only Agent Memory row (your per-user Memory toggle, when available, still appears alongside it — disabled, because agent conversations never use your User Memory), and the menu's trigger reads "MEMORY ON" so you can tell at a glance that the conversation uses the agent's shared memory.

:::note
See the [Memory](/features/memory/#agent-memory) reference section for the full model.
:::

## Next Steps

- [Memory](/features/memory/) — the full feature reference: how memory is scoped, the memory tools, configuration, and troubleshooting.
- [Glossary](/reference/glossary/) — Memory Engine, User Memory, Agent Memory, capture, and recall.
- [Memory and Persistence Patterns](/best-practices/memory-and-persistence/) — file and state persistence for agents, a separate concern from memory.

---

## Features

Source: https://docs.kindo.ai/features/

Kindo's feature modules cover AI-powered chat, autonomous agents, reusable skills, integrations with your existing tools, enterprise governance controls, and durable memory across conversations.

## Feature Hubs

---

## Agents

Source: https://docs.kindo.ai/features/agents/

Agents perform routines and processes on behalf of users, either autonomously or semi-autonomously. These routines correspond to Kindo's use cases and frequently take the form of DevSecOps playbooks, runbooks, ITOps routines, or standard operating procedures.

![A workflow agent configured for red team analysis on a SonicWall firewall, showing API request and LLM steps](../../../assets/docs/agents/red-team-agent-example.png)

Kindo agents are unique in that they can understand and utilize natural language when executing tasks. An agent can read a human-written document and use that information to inform its behavior, and can translate natural language intentions into programmatic actions such as API calls.

## Types of Agents

Kindo supports four agent types:

| Type                | Trigger        | Use Case                             |
| ------------------- | -------------- | ------------------------------------ |
| **Chatbot**         | User message   | Knowledge base Q&A, helpdesk         |
| **Manual Workflow** | Manual run     | Runbook execution, report generation |
| **Scheduled**       | Cron schedule  | Recurring reports, periodic checks   |
| **Triggered**       | External event | Incident response, alert triage      |

### Chatbots

A chatbot is an agent designed to respond to users with information gathered from its AI model and a set of knowledge base data.

**Example:** A helpdesk agent that answers questions about the setup process for a new company laptop or management of a development environment.

### Manual Workflow Agents

A manual workflow agent conducts a set of operations within a system of record. Like chatbots, workflow agents can utilize natural language resources such as knowledge bases, files, and articles. Additionally, workflow agents can source data from external sources via API calls and employ external tools to perform actions.

**Example:** An agent designed to manage and deploy a development infrastructure on a cloud platform.

### Scheduled Agents

A scheduled agent is a workflow agent that runs automatically on a cron schedule. These agents are ideal for recurring tasks like daily reports, weekly compliance checks, or periodic data synchronization. Scheduled agents have [organization-level quotas and scaling limits](/features/scheduled-agents/#scaling-limits-and-quotas).

**Example:** An agent that generates a weekly vulnerability report every Monday at 9 AM.

### Triggered Agents

A triggered agent is a special type of workflow agent that lies dormant while waiting for a specified event to occur -- such as a new entry in a ticketing system -- before launching a response. When the trigger event is detected, data from the event can be used by LLMs within the agent for analysis and decision-making.

Kindo supports two trigger flavors:

- **Integration Event triggers** activate on events from a connected integration (Jira, ServiceNow, Linear, etc.) and match against typed fields with structured conditions.
- **Direct Webhook URL triggers** expose a unique, token-protected URL that any external system can `POST` to. The trigger fires on every request, with optional natural-language gating against the request payload -- useful when no native integration trigger exists or when an arbitrary system needs to invoke the agent.

See [Creating and Managing Agents](/features/creating-agents/#creating-an-agent) for setup details.

**Example:** An agent that performs first-order root cause analysis for a platform engineering incident.

## Agent Steps

Agents are collections of **Agent Steps**: atomic operations conducted by Kindo on behalf of the user.

![Agent steps showing API requests and an LLM step for sorting vulnerabilities by severity](../../../assets/docs/agents/agent-steps-detail.png)

Kindo supports two step types:

### LLM Step

A step that requests a response from a permitted LLM. LLM steps are typically used for analysis, sorting information, and processing data gathered by previous steps.

### API Action Step

An operation where the agent makes a REST API call to request information or change state in an external system. API requests can be manually configured or generated from a natural language prompt using the Magic button.

API Action endpoints must be fully qualified hostnames. IP addresses, single-label hostnames such as `jira`, and cloud metadata hostnames are rejected when the step is saved, with an "Endpoint is invalid or includes a blocked domain" error. Endpoints generated dynamically by the agent are checked the same way when they run. At run time, Kindo also refuses hostnames that resolve to private, loopback, or link-local addresses, and redirects to any of these. A step refused this way fails with an "API request blocked" error.

**Note on Integration Actions:** When working with integrated systems like Jira or ServiceNow, you may see pre-built actions in the UI (like "add comment" or "change priority"). These are convenience shortcuts that use the integration's MCP tools behind the scenes — they are not a separate step type in the Kindo engine. Under the hood, they are API Action steps configured for that specific integration.

## Agent Memory and Coordination

As you scale from single agents to production systems, you'll need patterns for agent memory and multi-agent coordination:

- **[Memory](/features/memory/)** — Agent Memory gives an agent durable, consent-gated memory shared across all of its runs and users
- **[Memory and Persistence Patterns](/best-practices/memory-and-persistence/)** — Give agents persistent memory across runs using external systems and platform features
- **[Multi-Agent Coordination](/best-practices/multi-agent-coordination/)** — Orchestrate multiple agents to work together on complex workflows

## Next Steps

- [Create and manage agents](/features/creating-agents/) for step-by-step instructions
- [Create and manage skills](/features/skills/) to build reusable instruction packages for chats and agents
- [Version History](/features/creating-agents/#version-history) to inspect and restore previous versions of an agent
- [Configure integrations](/features/integrations/) to connect agents to external systems
- [Build Your First Workflow](/quickstarts/build-first-workflow/) for a hands-on multi-step workflow tutorial

---

## Creating and Managing Agents

Source: https://docs.kindo.ai/features/creating-agents/

Agents enable Kindo users to automate workflows including security runbooks, SRE playbooks, DevOps procedures, and ITOps response workflows. This guide covers how to create and manage agents.

## My Agents

After signing in, select the **Agents** tab to see your recently used agents and all agents available to you (both your own and shared).

![The Agents list view showing recently used agents with options to filter by type](../../../assets/docs/creating-agents/agents-list-view.png)

Filter agents by type using the tabs: **All Agents**, **Chatbots**, **Workflow Agents**, or **Triggered Agents**.

Each agent supports the following actions:

- **Share** -- Make the agent available to other users in your organization
- **Delete** -- Permanently remove the agent
- **Edit** -- Open the agent for modification
- **Run** -- Launch the agent

## Creating an Agent

Select **Create an Agent** at the top of the Agents window, then choose the agent type: **Triggered**, **Workflow**, or **Chatbot**.

![The agent type selection screen with options for Triggered, Workflow, and Chatbot agents](../../../assets/docs/creating-agents/agent-type-selection.png)

:::note
Not all AI Models support all file types. The model selected when you begin creating the agent is used by default, but can be changed after generation. Each step can use a different model.
:::

## Agent Configuration Panel

Both Triggered and Workflow agents support the Agent Configuration panel for natural language construction:

- **Name** -- Give the agent a name (auto-generated if blank)
- **Description** -- Summarize the agent's purpose (auto-generated if blank)
- **Instructions** -- Provide context about the agent's role, response format, and behavior
- **Tools** -- Choose the tool servers that every step and chat of the agent starts from. A step can turn a server on or off for itself. Select **Platform** to use [Kindo's own tools](/features/ai-chat/#tools), which need no integration connection.
- **Knowledge Store** -- Attach files, URLs, or websites as reference material

Integration tools use the runner's [active connections](/admin/integration-trust-domains/#default-behavior-no-pinned-connection)
by default. When your organization allows pinning, choose one or more fixed
connections for a server in the agent or step's Tools settings. Everyone running
the agent must have access to the connections they use; see
[pinned connection rules](/admin/integration-trust-domains/#pinned-connection-agent-authoring).

## Managing Steps

- To **delete** a step, open it and click the trash icon.
- To **reorder** steps, drag them into the desired sequence.
- Each step can be assigned a different AI model.

## Version History

Kindo automatically captures a version of an agent's configuration each time it is saved. Versions let you review prior states and roll back to a previous version if a change broke something. The audit log records every restore as an `Agent Restored to Previous Version` event.

### Opening the Version History Panel

From the agent builder, open the **Version History** panel via the version-history button in the builder header. The panel lists every captured version, newest first, grouped by day — a `TODAY` group at the top, followed by groups labeled with the date (e.g. `5/12/2026`). Each entry shows the time the version was saved and the email of the user who saved it.

The version currently being viewed is marked with a check icon. The most recent saved version represents the agent's current state.

### Read-Only Version Viewer

Selecting a version from the Version History panel opens it in a read-only viewer at:

```
/agents/builder/<workflowId>/version/<versionNumber>
```

The viewer renders the agent in a read-only layout with up to four top-level sections: **Agent Name**, **Agent Steps**, and **Agent Configuration** (description, instructions, tool servers, knowledge store, flags). If the agent has any triggers, an **Agent Triggers** section also appears. Each step shows its per-step configuration — model, interaction mode, prompt template, tool servers, and static content for LLM Steps; method, endpoint, headers, parameters, body, and abort-on-failure for API Action Steps. Every field is non-editable, and run controls are hidden. A banner at the top identifies the version and offers a **Restore this version** action.

Opening the version viewer and listing version history both require **`EDIT_WORKFLOW`** permission on the agent. Users with `VIEWER`-only access cannot open the Version History panel or load a historical version.

### Restoring a Previous Version

Restore replaces the agent's current configuration with the selected version's configuration. After restore:

- The agent's live state matches what the version captured.
- A new version row is written to history with a marker that it was restored from an earlier version. The source-version reference is stored structurally and surfaced in the audit log event, so the restore itself is auditable.
- The pre-restore state is captured as its own version too (if it wasn't already the latest), so nothing is lost — a second restore can roll forward again.

Like the version viewer itself, restore requires **`EDIT_WORKFLOW`** permission on the agent.

### What a Version Captures (and What It Does Not)

A version snapshots the **content** of an agent — its definition and the resources it depends on by reference. It deliberately does **not** snapshot sharing, secrets, or live external state.

**Captured:**

- Display name, description, system prompt
- Tool servers enabled for the agent as a whole, including any pinned connections
- Steps with all per-step configuration:
  - **LLM Steps** — prompt template, model selection, interaction mode, tool server configs, static content
  - **API Action Steps** — method, endpoint, headers, query/body parameters, secret references, abort-on-failure flag
- Inputs (template variables and their settings)
- Triggers (Integration Event, Cron, Direct Webhook) and their conditions
- Knowledge Store attachments
- The **Available as subagent** flag (see [Multi-Agent Coordination Patterns](/best-practices/multi-agent-coordination/#pattern-5-subagent-invocation)), and the demo-mode flag

**Intentionally not captured:**

- **Sharing and access controls** — org role, public role, user permissions, and user-group permissions are not part of version state. Restoring an old version does **not** change who can see or edit the agent (Google Docs / Notion model).
- **Direct Webhook secret tokens** — restore preserves the token on the live trigger row when the row was never deleted, but never re-issues a token.
- **Cron schedules' live registrations** — schedule and timezone are restored, but the underlying scheduler job is de-registered, so a restored cron trigger does not resume firing on its own.

**All triggers land inactive after restore.** Integration Event, Direct Webhook, and Cron triggers all come back disabled and must be explicitly re-enabled. This always-disable-on-restore policy is intentional: restoring a months-old agent should not silently resume a webhook listener, integration subscription, or cron job whose downstream side effects may no longer be desired.

## Exporting and Importing Agent Definitions

You can export an agent's definition to a portable JSON file and import it as a new agent — in another account, another organization, or another Kindo deployment. This is useful for sharing agents, keeping backups, and promoting an agent between environments.

### Exporting an Agent

Export is available in two places:

- **From the agent builder** -- Click **Download** in the builder header.
- **From the Agents list** -- Open an agent's row menu and select **Download**.

Either action downloads a `.json` file describing the agent. The export is a snapshot of the agent's definition only. It does **not** include sharing or access settings, secret values, or live integration credentials.

### Importing an Agent

1. On the **Create an Agent** screen, click **Import from file**.
2. Select one or more `.json` files that were exported from Kindo. You can import up to **20 files at once**.

Each file is imported as a **new** agent that you own — importing never overwrites an existing agent, and sharing settings are not carried over. When you import a single file, Kindo opens the new agent in the builder. When you import several, Kindo shows a summary of what succeeded and what failed.

### What an Import Carries Over

An imported definition contains the same content that a version captures — see [What a Version Captures (and What It Does Not)](#what-a-version-captures-and-what-it-does-not). In particular:

- **Reconnect your integrations.** Integration connections are not transferred. After importing, the builder flags any tool that needs a connection so you can connect your own.
- **Direct Webhook triggers are imported disabled.** The secret webhook URL is never exported, so you re-create the webhook after import.
- **Unavailable AI models fall back to your default.** If a step references an AI model you can't use — it doesn't exist in your organization, is restricted, or belongs to another organization — the step is set to your default model instead. The import still succeeds; switch the model in the builder if needed.
- **Secrets and Knowledge Store / static content must exist in your organization.** These are matched by reference. If one isn't available to you, the import of that file fails (see below).

### When an Import Can Fail

A file is rejected — and no agent is created from it — when:

- The file is not valid JSON, or is not a Kindo agent definition.
- The definition references a **secret** or **Knowledge Store / static content** item that does not exist in your organization or that you do not have access to.

Unavailable **AI models** and **integration connections** never fail an import — an unavailable model is swapped for your default, and an unavailable connection is left unset for you to reconnect.

When you import multiple files, each is processed independently. Valid files still import even if others in the same batch fail, and the failures are reported by file name so you know which ones to fix.

## File Library

Add files to Kindo's library from two locations:

1. **From Chat** -- Click the **+** button in the query bar
2. **When Creating an Agent** -- Click **Add Knowledge Store**

Both methods open the File Library where you can select existing files or upload new ones.

![The File Library showing uploaded files with checkboxes for selection](../../../assets/docs/creating-agents/file-library.png)

## Agent Types Reference

Kindo supports four agent types, each designed for different automation patterns:

| Type                | Trigger        | Best For                                                       |
| ------------------- | -------------- | -------------------------------------------------------------- |
| **Chatbot**         | User message   | Knowledge base Q&A, helpdesk, conversational interfaces        |
| **Manual Workflow** | Manual run     | Runbook execution, one-off reports, on-demand analysis         |
| **Scheduled**       | Cron schedule  | Recurring reports, periodic compliance checks, daily summaries |
| **Triggered**       | External event | Incident response, alert triage, ticket automation             |

### Choosing an Agent Type

**Start with a Chatbot** when you need conversational interaction or knowledge base access.

**Use a Manual Workflow** when you need to perform a sequence of operations on demand, especially when those operations involve API calls or data processing.

**Add a Schedule** when the same workflow needs to run repeatedly (daily security reports, weekly compliance scans).

**Add a Trigger** when the workflow should respond to external events. Use an **Integration Event** trigger for events from a connected integration (new tickets, security alerts), or a **Direct Webhook URL** trigger when no native integration exists or when an arbitrary system needs to invoke the agent.

## Best Practices

As you move from simple agents to production workflows, consult these guides:

- **[Prompt and Agent Configuration Management](/best-practices/prompt-and-agent-configuration/)** — Version control, testing, and governance for production agents
- **[Working with Large Context](/best-practices/working-with-large-context/)** — Techniques for handling large documents, logs, and tool outputs
- **[Memory and Persistence Patterns](/best-practices/memory-and-persistence/)** — Give agents persistent memory across runs using external systems
- **[Multi-Agent Coordination](/best-practices/multi-agent-coordination/)** — Orchestrate multiple agents to work together on complex workflows

---

## AI Chat

Source: https://docs.kindo.ai/features/ai-chat/

Kindo AI Chat provides a secure, enterprise-grade interface for interacting with AI models. Unlike consumer chatbots, every conversation runs through Kindo's governance layer with DLP filtering, audit logging, and role-based access controls.

## Key Capabilities

- **Multi-model access** -- Switch between 26+ LLMs from the same interface. Choose General Purpose, Reasoning, Long Context, or Cybersecurity-focused models depending on your task.
- **File attachments** -- Upload documents, logs, configurations, images, and other files for the model to analyze. Supported direct and tool-assisted formats include text, PDF, CSV, JSON, code files, images for vision models, and audio/video conversion when available.
- **Tool integration** -- Enable Library Search, URL Search, and Web Search to give the model access to your knowledge store, specific URLs, or live internet results.
- **Conversation history** -- Review past conversations filtered by date, type (your own or shared), and topic. Conversations persist across sessions.
- **Sharing** -- Share conversations with team members for review or collaboration.

## Enterprise Controls

Every chat interaction is protected by Kindo's security framework:

| Control                | What It Does                                                                                              |
| ---------------------- | --------------------------------------------------------------------------------------------------------- |
| **DLP Filters**        | Automatically detect and redact sensitive data (PII, credentials, secrets) before it reaches the AI model |
| **Audit Logging**      | Every message, model selection, and tool use is logged to your organization's audit trail                 |
| **RBAC**               | Administrators control which models and tools are available to each user or group                         |
| **Model Restrictions** | Disable specific models organization-wide or restrict them to certain roles                               |

## Model Categories

Models are organized by capability:

| Category            | Best For                                               | Examples                        |
| ------------------- | ------------------------------------------------------ | ------------------------------- |
| **General Purpose** | Most tasks -- writing, analysis, summarization         | Claude, GPT-4                   |
| **Reasoning**       | Complex analysis, multi-step problem solving           | OpenAI o-series                 |
| **Long Context**    | Large documents, codebases, lengthy analysis           | Models with 100k+ token windows |
| **Cybersecurity**   | Threat analysis, vulnerability assessment, red teaming | DeepHat                         |

## Working with Files

Attach files to provide context for your queries:

![Attaching files to a chat query using the + button](../../../assets/docs/getting-started/attach-files.png)

1. Click the **+** button next to the query bar.
2. Select files from your machine.
3. Choose how the model should process them:
   - **For All Files** -- Apply your query to the entire collection
   - **Per File** -- Apply your query to each file independently

Image attachments can be provided directly to supported vision models. Audio
and video files are processed through file conversion or transcription tools
rather than being sent directly to chat models as raw media. Kindo shows an
unsupported file type message when a provider rejects a file part that reached
the model request.

## Tools

Toggle tools to extend the model's capabilities:

![The Tools panel with Library Search, URL Search, and Web Search toggles](../../../assets/docs/getting-started/tools-selection.png)

- **Library Search** -- Searches your organization's uploaded knowledge base using semantic search (embeddings).
- **URL Search** -- Fetches and includes content from a specific URL you provide.
- **Web Search** -- Searches the live internet for current information.
- **Platform** -- Creates and edits agents, enables or disables their tool servers, and attaches or removes existing skills and knowledge. It also lists agents, reads their configuration, starts standalone runs, and inspects runs and conversations. Organization admins can also [look up members](/reference/tool-catalog/#platform-tools). Successful creation and edits show an agent preview card with Open Agent and Start chat actions. All actions use your existing access permissions; no integration account is required for Platform itself. Skills and Knowledge Store must be enabled to manage those attachments.
- **Integrations** -- Uses your connected accounts to work with external services.

Tools are enabled per-message and can be combined.

For integrations, choose your [active accounts](/admin/integration-trust-domains/#default-behavior-no-pinned-connection)
or [pin connections](/admin/integration-trust-domains/#pinned-connection-agent-authoring)
to a chat. External clients can use integration and Platform tools through the
[MCP API](/apis/mcp/quickstart/).

## Context Usage

Once the assistant has responded in Actions mode, a circular indicator next to the model selector shows how much of the selected model's context window has been used. (In Ask mode or before the first response, the model selector shows a bolt icon instead.) The ring fills and changes color as the conversation grows: green under 60%, yellow at 60-79%, red at 80% and above. Hover the ring for a tooltip with the current token count and -- when available -- the context window total, tokens remaining, and conversation credits consumed. The ring pulses while the model is responding and briefly afterward while the latest counts are refreshed.

When a long conversation approaches the context limit, Kindo automatically compacts it: earlier messages are summarized so the most relevant context is kept while the session continues. A **Context summarized** marker appears in the conversation when this happens, so the change is visible rather than silent. You do not need to start over or manage the context yourself -- your conversation keeps working as it grows.

## Next Steps

- [Create an Agent](/features/creating-agents/) to automate recurring chat-based tasks
- [Configure Security Controls](/admin/security-controls/) to manage DLP and model access
- [Learn about Integrations](/features/integrations/) to connect external data sources

---

## Scheduled Agents

Source: https://docs.kindo.ai/features/scheduled-agents/

Scheduled agents are workflow agents that run automatically on a cron schedule. They are ideal for recurring tasks like daily reports, weekly compliance checks, or periodic data synchronization.

## How Scheduling Works

Each scheduled agent is backed by a **cron trigger** that determines when it runs. Kindo uses standard 5-field cron expressions (minute, hour, day-of-month, month, day-of-week) and supports timezone-aware scheduling.

When you create a scheduled agent, you define:

- A **cron expression** or natural-language schedule (e.g., "every Monday at 9 AM")
- A **timezone** for the schedule to run in
- The **workflow steps** the agent executes on each run

## Scaling Limits and Quotas

Scheduled agents have organization-level quotas to ensure platform stability. These limits apply to the total number of **enabled** scheduled agents across all users in your organization.

### Default Limits

| Limit | Default Value | Description |
| --- | --- | --- |
| **Max scheduled agents** | 5 per organization | Total number of enabled scheduled agents allowed |
| **Minimum run interval** | 60 minutes | Shortest allowed interval between consecutive runs |

### How Quotas Work

- Quotas are counted at the **organization level**, not per user.
- Only **enabled** scheduled agents count toward the quota. Disabling a scheduled agent frees up a slot.
- The quota is checked when **creating** a new scheduled agent or **re-enabling** a disabled one.
- If your organization has reached its quota, the "Build Agent" button for scheduled agents will be disabled with an explanatory message.
- Your current usage is displayed on the agent creation screen (e.g., "3 / 5 scheduled agents used").

### Requesting Higher Limits

If your organization needs more scheduled agents or shorter run intervals, contact your Kindo account representative or reach out to [support](mailto:support@kindo.ai). Limits can be adjusted per organization based on your plan and usage patterns.

## Best Practices

### Choose Appropriate Intervals

- **Hourly or less frequent** schedules are recommended for most use cases.
- Consider whether your data sources update frequently enough to justify shorter intervals.
- Longer intervals reduce credit consumption and system load.

### Design for Idempotency

Scheduled agents should produce consistent results when run multiple times. If a run fails or is retried, the agent should handle duplicate data gracefully.

### Monitor Agent Runs

Review your scheduled agent run history regularly in the **Agent Monitoring** tab. Look for:

- Failed runs that may need investigation
- Runs that take unexpectedly long to complete
- Agents that are no longer needed and can be disabled to free quota

### Manage Your Quota

- **Disable unused agents** rather than deleting them if you may need them again. Disabled agents don't count toward your quota.
- **Consolidate similar agents** where possible. A single agent with multiple steps is often more efficient than several single-step agents.

## Creating a Scheduled Agent

For a detailed walkthrough, see the [Scheduled Vulnerability Report](/best-practices/scheduled-vulnerability-report/) tutorial.

## Next Steps

- [Creating and Managing Agents](/features/creating-agents/) for general agent setup
- [Agents Overview](/features/agents/) for all agent types
- [Scheduled Vulnerability Report](/best-practices/scheduled-vulnerability-report/) for a hands-on tutorial

---

## Model Configuration

Source: https://docs.kindo.ai/features/models/

This guide explains how Self-Managed Kindo installations define and maintain **global models** -- the system-wide LLMs (and related models like embeddings or transcription) that power workflows, chat, ingestion, and other core experiences.

In a self-managed environment, you add models to Kindo, map them to Unleash feature variants, and keep those mappings up to date when models are replaced.

:::tip[Deploying model infrastructure?]
Before configuring models in Kindo, you need working inference endpoints. See [Prepare AI Models](/deploy/prepare-ai-models/) for how to deploy and verify self-hosted models (vLLM, context window sizing, tool-call parsers) or connect cloud API providers.
:::

## Unleash Features and Strategy Variants

Each key below is an Unleash feature whose **variant payload** contains one or more global model IDs. The backend and frontend read these variants to decide which models to use.

### Required Features

| Feature Key | Description |
|---|---|
| `AUDIO_TRANSCRIPTION` | Converts audio to text |
| `CRON_EXPRESSION_GENERATION` | Generates cron expressions from natural language schedule descriptions |
| `DEFAULT_WORKFLOW_STEP_MODEL` | Default model for workflow step execution |
| `EMBEDDING_MODELS` | Models for generating text embeddings |
| `INGESTION_WORKERS` | Models for data ingestion and extraction |
| `INTERNAL_AUTO_GENERATION` | Internal model for automatic content generation and internal worker tasks |
| `LOCAL_STORAGE_CHAT_ACTIONS_MODELS` | Fallback default chat model for the model dropdown and chat action selection. Applies when an org admin has not chosen a default chat model in Settings → Models (or the chosen model is unavailable) |
| `TOOL_CALLING_MODELS` | Models that support tool/function calling (used to filter model selection in chat UI) |

### Optional Features

| Feature Key | Description | Notes |
|---|---|---|
| `API_STEP_GENERATION` | Models for generating API steps in workflows | |
| `DYNAMIC_API_REQUEST_PARSER` | Parses dynamic API requests | |
| `SLACK_MESSAGE_GENERATION` | Generates Slack messages | Only if Slack integration is enabled |
| `MULTIMODAL_MODELS` | Models with image/multimodal input support | Only if multimodal chat is enabled |

## Minimum Model Requirements

Self-Managed Kindo needs baseline global models to function. Without them, core flows like chat, workflow execution, ingestion, and indexing will fail.

### Absolute Minimum Set

| Model Type | Purpose | Recommendations |
|---|---|---|
| **Embedding model** | Semantic search, retrieval, and indexing | Open source: BAAI/bge-m3. Hosted: Gemini embedding |
| **Strong/large model** | Complex reasoning, workflow execution, long-form generation | Open source: gpt-oss 120B. Hosted: Gemini 2.5 Pro, Claude 4.5, GPT 5.2 |
| **Audio transcription** | Audio file processing, voice notes, transcription workflows | Open source: Faster Whisper. Hosted: Deepgram |

### Recommended Additional Models

- **Small model** (title generation, quick summaries, low-latency steps): Gemma 3 or Llama 3.2 7B
- **Security-focused**: DeepHat V3
- **Multimodal**: Gemini 2.5 Pro (image + text)

## Managing Models

### Overview of Steps

1. Add the new model in **Settings → Models → Add model**.
2. Update Unleash variants to reference the new model IDs.
3. Delete the old model with replacement.

:::caution
If the model you are deleting is still referenced by Unleash, the response will list the feature flags that need updates. Update those variants first, then retry the delete.
:::

### Add a Self-Managed Model in the UI

A self-managed model is a model you already run or pay for somewhere else (a self-hosted vLLM box, a serverless endpoint such as Together, Fireworks, or Groq, an internal inference gateway, or your own OpenAI account) that you want to use inside Kindo for chat and agents. The endpoint must be **OpenAI-compatible** (it accepts OpenAI-style chat completion requests), or an **Anthropic Messages** endpoint whose URL ends in `/anthropic`, such as Claude on Microsoft Foundry. The Add Model form asks only for the handful of facts any such endpoint needs, in plain English.

| Field | Required? | What to enter |
|---|---|---|
| Display name | Yes | The name you'll see in Kindo when choosing this model, for example `Llama 3.3 70B (self-managed)`. |
| Model ID | Yes | The model's name exactly as your endpoint expects it in a request, for example `Qwen/Qwen3.7-Max`, `llama-3.3-70b`, or `gpt-4o`. Use exactly what your provider or server calls it. For Azure OpenAI or Microsoft Foundry, use your deployment name. |
| Endpoint URL | Yes | The base URL of your model's API, for example `https://api.together.xyz/v1`, `http://my-vllm:8000/v1`, or `https://your-resource.openai.azure.com`. Paste exactly what your provider gives you — Kindo tidies it up (trims it, drops a trailing slash or a mis-pasted `/chat/completions`, and adds the version segment if your base URL doesn't already include one). |
| API version | No | Leave blank for most providers. Only needed when your endpoint requires an `api-version` query parameter — for example an Azure OpenAI deployment pinned to a dated version such as `2024-10-21`. |
| API key | Yes | The key your endpoint uses to authenticate. Stored encrypted; never shown again. |
| Context window | Yes | Your model's maximum context length in tokens, from your provider's docs, for example `128000`. Kindo uses this to keep long conversations within the model's limit. |
| Max output tokens | Yes | The maximum number of tokens the model should generate per response, from your provider's docs, for example `4096`. |

#### Endpoint URL examples

Paste the base URL your provider hands you. Common shapes already work as-is:

- OpenAI: `https://api.openai.com/v1`
- Together: `https://api.together.xyz/v1`
- Groq: `https://api.groq.com/openai/v1`
- Fireworks: `https://api.fireworks.ai/inference/v1`
- Self-hosted vLLM: `http://<host>:8000` (Kindo appends `/v1` for you)
- Azure OpenAI: `https://<your-resource>.openai.azure.com` (Kindo routes to Azure's OpenAI-compatible `/openai/v1` surface for you)
- Claude on Microsoft Foundry: `https://<your-resource>.services.ai.azure.com/anthropic` (see [Claude on Microsoft Foundry](#claude-on-microsoft-foundry))

#### Azure OpenAI

Azure OpenAI endpoints work like any other OpenAI-compatible endpoint:

- **Most deployments:** paste your resource URL (for example `https://my-resource.openai.azure.com`), set Model ID to your **deployment name**, and leave API version blank. Kindo talks to Azure's OpenAI-compatible `v1` surface, which needs no `api-version` parameter.
- **Deployments pinned to a dated API version:** fill in the API version field (for example `2024-10-21`) and Kindo dispatches through Azure's versioned API instead. Pasting the full target URI from the Azure portal (`https://…/openai/deployments/<name>/chat/completions?api-version=…`) also works — Kindo picks up the `api-version` from the URL automatically.

#### Claude on Microsoft Foundry

Microsoft Foundry serves Claude only through the Anthropic Messages API, not an OpenAI-compatible route. An Endpoint URL whose path ends in `/anthropic`, `/anthropic/v1`, or `/anthropic/v1/messages` tells Kindo to use that API:

- Paste `https://<your-resource>.services.ai.azure.com/anthropic` (the full `/anthropic/v1/messages` URL from the Foundry portal also works).
- Set Model ID to your **deployment name**. Any deployment name works.
- Leave API version blank. The Messages API does not use one, so Kindo ignores it for these endpoints.
- Set Max output tokens within the model's limit. The Messages API requires it on every request.

Kindo authenticates with your key in the `x-api-key` header and translates chat and tool calls between Kindo and the Messages API for you.

:::note
The URL must point at your chat completions or Anthropic Messages endpoint. URLs for other APIs (for example ones ending in `/embeddings` or `/responses`) are rejected so a wrong paste can't silently mis-configure the model.
:::

#### Test & Save

**Test & Save** (the primary button) sends a real request to your endpoint (a chat completion, or a Messages request for an `/anthropic` endpoint) before anything is saved, and tries again in the shapes described below when the endpoint asks for one. If the test fails, nothing is created: the form stays filled in and the error points at the field to fix: a rejected key highlights **API key**, an unknown model name highlights **Model ID**, an unreachable or timed-out endpoint highlights **Endpoint URL**, a too-high **Max output tokens** highlights that field and names the model's maximum when the provider reports it, and a rejected request parameter is called out by name. From the failure banner you can either **Edit** the form and test again, or **Save anyway** to store the config without a passing test.

Some models reject the `max_tokens` request parameter and accept only `max_completion_tokens`, for example some newer Azure OpenAI deployments. When your endpoint rejects `max_tokens` by name, **Test & Save** sends the test once more with `max_completion_tokens`. If that passes, Kindo saves the model so its requests carry your **Max output tokens** as `max_completion_tokens`. **Save without testing** can't detect this, so save such a model with **Test & Save**.

Kindo chat always offers the model tools. Some Azure OpenAI reasoning models reject tools on chat completions and point to the Responses API instead. For an Azure OpenAI endpoint, the test includes a tool, as a real chat does. When the endpoint rejects it that way, **Test & Save** sends the test once more to the Responses API. If that passes, Kindo saves the model so its requests use the Responses API, where chat with tools works. **Save without testing** can't detect this either. On an endpoint with an API version, the Responses API needs version `2025-03-01-preview` or later.

**Save without testing** skips the test entirely — useful when the endpoint is temporarily down, a self-hosted model is cold-starting, or you don't want to spend a request on a quota-limited endpoint.

The model list shows the outcome as a chip next to each self-managed model: **Verified** (last test passed), **Untested** (saved without a passing test), or **Failed** (a later re-test failed — hover the chip for the reason). Kindo's built-in global models are managed for you and carry no chip.

### Models with Multiple Providers (Model Groups)

A model in Kindo is not tied to one endpoint. You can attach several provider endpoints to the same model — for example the same model served from two regions of your cloud provider, or a self-hosted model behind two vLLM endpoints. In the Add Model form, pick an existing model in the **Model** field instead of typing a new name, and the endpoint you are configuring is added as another provider for it. Attaching and reordering a model's providers is an organization-admin action on the Enterprise tier, in installations where multi-provider models are enabled; the endpoints you attach belong to the model's own provider.

People always pick the **model**, never a specific provider. Which of the model's providers serves a given request is not decided until the request is already on its way, by the model's [fallback chain](#fallback-chain) and its [session affinity](#session-affinity).

Because of that, **a model group behaves as the lowest common denominator of its providers**:

| Control | How the group resolves it | Effect |
|---|---|---|
| Context window | **Smallest** across the model's enabled providers | A 32k provider under a 200k model makes the whole model 32k. |
| Tool limit | **Smallest** across the model's enabled providers | An OpenAI or Azure OpenAI endpoint accepts at most 128 tools per request, so one of them makes 128 tools the model's effective limit. |
| DLP filters | **Strictest** across the model's providers | A filter that redacts for any provider redacts for the whole model. |
| Provider enablement | **Strictest** across the model's providers | A provider your organization has disabled in its security controls makes the whole model unavailable, even where that provider is attached to the model only through a disabled endpoint. (Turning off one endpoint in the model's provider list is a different thing — see [Fallback chain](#fallback-chain).) |

#### Why the group uses the minimum

Two reasons, both about the request being decided before the provider is:

- **Routing is blind and failover is silent.** Kindo has to fix the capacity budget for a request *before* it knows which provider will serve it — and a request that fails over mid-flight can land on a different provider than it started with. The only budget that is valid for every provider the request could reach is the smallest one.
- **Runs have to replay identically.** The budget is recorded when the request starts so that a resumed or retried run reproduces exactly the same conversation. If the budget tracked whichever provider happened to answer, a retry that fell back to a smaller provider would overflow it.

#### Group providers with like-for-like capacity

Pick providers that are close to each other in capability, so nothing is stranded at the floor:

- **Match context windows.** Attaching a 32k endpoint to a 200k model does not add 32k of capacity — it removes 168k from the model. If a provider is much smaller, give it its own model instead, so people can choose it deliberately.
- **Match tool support.** If tool-heavy agents use the model, an OpenAI or Azure OpenAI endpoint accepts at most 128 tools per request — a request carrying more can fail whenever that endpoint serves it, so the model's effective tool limit becomes 128.
- **Match governance.** A provider your organization has disabled, or one with stricter DLP filters, applies its rules to the whole model, not just to the requests it serves.

The Add Model form tells you about this before you save: once you pick a model to attach to, it shows the context window the new endpoint should clear and warns you when the endpoint would newly limit the model's tool use.

{/* The `#fallback-chain` and `#session-affinity` slugs are linked from the
    product UI and from announcements. Renaming either heading breaks those
    deep links — change the links in the same commit if you must. */}

#### Fallback chain

The providers attached to a model form a **fallback chain**: an ordered list, lowest priority number first, and that is the order the provider list shows in **Settings → Models**. Move a provider up or down to change the chain. Turning a provider off takes its endpoint out of the chain — the model's other endpoints keep serving — and leaves its configuration in place so you can turn it back on.

Two things move a request off the provider that was chosen for it:

- **Retries.** A transient failure — a timeout, a rate limit, or a provider-side error — is retried inside the model, up to twice. Failures a retry cannot fix, such as a malformed request, are not retried.
- **Descent to the next priority level.** When the retries are used up, the request is re-aimed at the next priority level down the chain. This is also how an interrupted streamed response continues: it resumes on the next level, and text already streamed to the reader is not repeated. Most errors take this path once, not only transient ones — a request whose content the model rejected outright, or one that overflowed the context window, is returned to the caller instead.

Descending the chain needs at least two distinct priority levels. An endpoint you attach starts at the top priority, which ties it with the provider the model already had, and providers that share a priority number share traffic rather than one preferring the other — a retry can still move a failed request to the other, but there is no lower level to descend to. So if you want a deliberate primary with a backup behind it, move the rows up or down once: the list renumbers into distinct levels and the chain becomes strict.

A provider that fails persistently is put in **cooldown**: it is dropped from the chain for about half a minute and then becomes eligible again on its own, so a hard-down endpoint is not re-tried by every request in the meantime and recovery needs no administrator action. Cooldown only ever removes a provider that has an alternative — a model with a single provider is never cooled out of its own chain, because there would be nothing left to serve it.

#### Session affinity

Providers cache the part of a prompt they have already seen, and that cache lives on the endpoint that served the request — it is not shared between two endpoints of the same model. Because a conversation resends its whole history on every turn, a cache hit is the difference between the provider re-reading the entire conversation and re-reading only the newest turn. That drives both **latency** (how fast a long conversation starts responding) and **cost** (cached input is billed at a fraction of fresh input). A long conversation bounced between two providers would pay full price for the same history again on every switch.

So once a conversation is under way, Kindo keeps it on the provider that served its earlier turns where it can — **session affinity**:

- **The pin is per conversation, and it is best effort.** It exists to keep a cache warm; it is not a promise about which provider answers you. It covers the conversations Kindo drives — chat and agent runs. Requests sent straight to the Kindo APIs are not pinned.
- **The pin expires.** It is upper-bounded by a time-to-live (one hour by default), so a conversation picked back up much later is routed fresh. The lifetime is deliberately longer than the provider cache windows it protects: a pin whose cache has already lapsed simply re-warms the same endpoint.
- **Health beats affinity.** If the pinned provider is in cooldown or otherwise out of the healthy set, the conversation falls through to a surviving provider and pins to whichever one serves it. Affinity never holds a conversation on a dead endpoint.
- **Until it is cooled out, though, the pinned provider is still preferred** — including over a healthy provider at a lower priority level. A conversation can therefore keep attempting a failing endpoint for the turn or two it takes cooldown to remove it, which is what recovery looks like from the inside rather than a stuck conversation.
- **A single-provider model is unaffected** — with one endpoint there is only one choice.

What this means when you plan a model's providers: adding a second provider to a busy model does not cool the caches you already have, because conversations in flight stay where they are and only later ones spread out. It also means the providers worth grouping are the ones that are close in capability (see above) — a chain whose members are interchangeable is the chain that keeps caches warm, since every fallback lands on a cold cache.

#### One provider is a complete configuration

A model has exactly one provider configured unless an administrator attaches another, and that is the state every model starts in. A single-provider model has no chain to descend and no pin worth observing, so everything above describes behavior you opt into per model, one provider at a time — there is nothing to migrate, nothing to re-configure, and nothing required of an administrator who never attaches a second provider.

---

## Integrations Setup

Source: https://docs.kindo.ai/features/integrations/

Kindo supports integrations using Nango for authentication and the MCP protocol for agent access to external systems. Most MCP servers are built in-house and run by the customer as part of a self-managed installation, though a growing number of official hosted MCPs can be accessed directly.

:::tip
This page covers infrastructure setup. For governance of who can use which integration and which tools (per-user-group scoping, shared connections, etc.), see [Tool Action Access Controls](/admin/rbac-tool-actions/). For the enterprise pattern of isolating an integration's identity to a single team -- so other teams cannot see or use the connection -- see [Integration Identity Isolation](/admin/integration-trust-domains/).
:::

## Nango Setup

### Connecting Nango to Your Installation

![Architecture diagram showing the connection between Nango and a Kindo installation](../../../assets/docs/integrations/nango-kindo-connection.png)

#### 1. Set Environment Variables in Kindo

| Variable                           | Description                                                                                                                                                                                                           | Required Services   |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- |
| `NANGO_SECRET_KEY`                 | Shared secret key for Nango integrations                                                                                                                                                                              | api, task-worker-ts |
| `NANGO_URL`                        | Host on the Ingress pointing to the `nango` service (must match your Nango dashboard URL)                                                                                                                             | api, task-worker-ts |
| `API_INTEGRATION_WEBHOOK_BASE_URL` | The URL of your API service with `/webhook/integration-connection` appended (e.g., `https://

For self-managed Kindo installs, this secret is managed by the installer and applied to both Nango and the Kindo services that use it.

### Configuring New Integrations

The set of integrations available in a Self-Managed install is driven by the Kindo **integration catalog** that ships with each release. On deploy — and on every `kindo integrations apply` — the reconciler creates the corresponding Nango integration instances for the integrations you have enabled, so for a production install you do **not** hand-create them in the Nango dashboard.

The Nango dashboard is still where you supply the provider-side configuration the reconciler cannot generate: the OAuth Client ID and Client Secret for `OAUTH2` integrations (see [OAUTH2 Integrations](#oauth2-integrations)) and any webhook secrets (see [Integration Webhooks](#integration-webhooks)).

For local or ad-hoc experimentation you can still configure an integration directly in the Nango dashboard (**Integrations** > **Configure New Integration** > select the integration and auth method):

![Nango dashboard showing integration configuration](../../../assets/docs/integrations/nango-integration-config.png)

### Supported Integrations

The integrations below have their authentication method and setup notes on this page. For the full inventory of integrations and the tools each one exposes to an agent, see the [Tool Catalog](/reference/tool-catalog/).

| Integration                | Auth Method | Notes                                                 |
| -------------------------- | ----------- | ----------------------------------------------------- |
| Azure DevOps               | BASIC       |                                                       |
| Box                        | OAUTH2      |                                                       |
| Cisco Catalyst             | BASIC       |                                                       |
| Cisco FMC                  | BASIC       |                                                       |
| Cofense Triage             | OAUTH2_CC   |                                                       |
| CrowdStrike Falcon         | OAUTH2_CC   |                                                       |
| Datadog                    | API_KEY     |                                                       |
| Dropbox                    | OAUTH2      | Requires file and account scopes                      |
| GitHub                     | OAUTH2      | Scopes: repo, read:org, user                          |
| GitLab                     | OAUTH2      | Scopes: api                                           |
| Google Docs                | OAUTH2      | Requires documents and drive scopes                   |
| Google Drive               | OAUTH2      | Requires userinfo and drive scopes                    |
| Google SecOps              | OAUTH2      | Configured per connection                             |
| Grafana                    | API_KEY     |                                                       |
| Graylog                    | BASIC       |                                                       |
| Jira                       | OAUTH2      | Requires Jira API and User Identity API scopes        |
| Linear                     | OAUTH2      | Scopes: admin, read, write                            |
| Microsoft Entra ID         | OAUTH2      |                                                       |
| Microsoft OneDrive         | OAUTH2      | Requires Files scopes                                 |
| Microsoft Outlook Calendar | OAUTH2      | Requires Microsoft Graph calendar and contacts scopes |
| Microsoft Teams            | OAUTH2      | Requires Teams and Chat scopes                        |
| Neo4j                      | BASIC       |                                                       |
| NVD                        | API_KEY     |                                                       |
| SailPoint                  | OAUTH2_CC   |                                                       |
| SAP S/4HANA                | BASIC       | OData and RFC variants                                |
| ServiceNow                 | OAUTH2_CC   |                                                       |
| Slack                      | OAUTH2      | Requires channels, chat, and users scopes             |
| Smartsheet                 | OAUTH2      | Requires sheets, folders, and workspaces scopes       |
| Sourcegraph                | API_KEY     |                                                       |
| Splunk                     | API_KEY     |                                                       |
| Sumo Logic                 | BASIC       |                                                       |
| Tenable                    | API_KEY     |                                                       |

:::tip
For Microsoft integrations (Entra ID, Defender, Teams, Purview, Intune, etc.), see [Enterprise Application Permissions](/admin/enterprise-app-permissions/) for the full list of API permissions each app registration requires.
:::

### OAUTH2 Integrations

For OAUTH2 integrations, first create an OAuth app within the target integration. The callback URL should be `

:::note
Connections created before configuring webhooks must be reauthenticated (deleted and reconnected in the Kindo UI).
:::

### Jira Webhooks

No additional setup is needed for Jira webhooks.

## Enabling Integrations

Kindo keeps each installation's `IntegrationConfig` rows in sync with the **integration catalog** that ships with the release — there is no manual sync step to run. Whenever the platform is deployed or upgraded, the reconciler registers the selected integrations with Nango and reconciles their metadata against the catalog automatically.

Which integrations are active is driven by `install-contract.yaml` and applied with the `kindo` CLI:

```bash
# See what is available and which are enabled
kindo integrations list

# Enable one or more (prompts for OAuth credentials where needed)
kindo integrations enable github slack

# Register the enabled integrations with Nango and reconcile their metadata
kindo integrations apply
```

`kindo integrations apply` is idempotent and can be re-run any time the contract's integrations change. It deploys the `integrations-reconciler` release, whose reconcile job registers each selected integration with Nango and reconciles its `IntegrationConfig` metadata against the catalog, marking each selected integration verified. For the full operator reference — including `disable`, `bootstrap`, and `status` — see [Operate](/deploy/operate/) and [Install with kindo-cli](/deploy/install-with-kindo-cli/).

Then confirm in the Kindo app under **Command Center** > **Manage Your Integrations**:

![The Kindo integrations settings showing available API providers](../../../assets/docs/integrations/kindo-available-integrations.png)

## MCP Server Setup

Each integration's MCP routing — the `mcpServerUrl` and `supportsWebhooks` fields on its `IntegrationConfig` row — is owned by the integration catalog and applied by the reconciler. Do **not** set these by hand: any direct edit to the `IntegrationConfig` table is overwritten the next time the platform is deployed or `kindo integrations apply` runs.

The catalog provides each integration's MCP server URL and the reconciler writes it to the row. The stored values look like:

```
http://mcp-grafana.mcp:80/mcp
http://mcp-box.mcp:80/mcp
http://mcp-unified.mcp:5050/linear/
```

The stored URL is called exactly as written and includes the full path: `/mcp` for standalone MCP servers, or the integration's mount path (e.g. `/linear/`) for servers hosted by the unified MCP service. Integrations that support event webhooks (for example Jira and Linear) have `supportsWebhooks` set from the catalog as well; see [Integration Webhooks](#integration-webhooks) for the provider-side configuration those require.

---

## Governance and Controls

Source: https://docs.kindo.ai/features/governance/

Kindo provides a comprehensive governance framework that ensures AI usage across your organization remains secure, compliant, and auditable. Every interaction -- whether through chat, agents, or the API -- passes through these controls.

## Core Governance Capabilities

### Data Loss Prevention (DLP)

DLP filters run on every request and response, scanning for sensitive data before it reaches AI models:

- **PII Detection** -- Automatically identifies and redacts personal information (names, emails, phone numbers, SSNs)
- **Credential Detection** -- Catches API keys, passwords, tokens, and connection strings
- **Custom Patterns** -- Define organization-specific patterns to protect proprietary data
- **Per-Model Controls** -- Enable or disable DLP filters for specific models

DLP uses Presidio for entity recognition and can be configured by administrators under [**Settings > Organization > Model Access & DLP**](https://app.kindo.ai/?settings=model-access-and-dlp).

When your organization has gateway DLP enabled, tool data fetched by external MCP clients through the [MCP API](/apis/mcp/quickstart/) is covered too. Those clients call their own model, so there is no model or provider to resolve a policy against — the gateway instead applies the strictest combination of your organization's, your user groups', and the individual tool's DLP settings, and refuses to return content it cannot inspect. See [MCP API data loss prevention](/apis/mcp/dlp/).

### Models Served by Several Providers

A model can be served by more than one provider endpoint (see [Models with Multiple Providers](/features/models/#models-with-multiple-providers-model-groups)). Any of those providers can serve a given request, so **security controls resolve as the strictest across the whole model, not per provider**: a DLP filter that redacts for one of the model's providers redacts on every request to that model, and disabling any one of its providers makes the whole model unavailable to your organization. There is no configuration in which a request slips through under the more permissive provider's rules.

The same intersection rule governs capacity — the model runs at the smallest context window and tool limit across its providers. Capacity and security are two halves of one idea: a model group is only ever as capable and as permissive as its most restrictive provider.

### Role-Based Access Control (RBAC)

Control who can do what across the platform:

| Role | Capabilities |
|------|-------------|
| **User** | Chat, run shared agents, use approved integrations |
| **Agent Creator** | Create and share agents, configure workflows |
| **Administrator** | Manage models, integrations, security settings, users |

Administrators assign roles and manage permissions through the **Organization** tabs in Settings.

Beyond role-based access, Kindo provides **tool action access controls** that govern which integrations and specific tool actions are available to users and AI agents. Administrators configure these at the organization level and refine them per user group. See [Tool Action Access Controls](/admin/rbac-tool-actions/) for the full configuration guide.

### Audit Logging

Every action in Kindo is logged:

- Chat messages and model responses
- Agent executions and step-by-step results
- API calls and authentication events
- Configuration changes and administrative actions
- Integration connections and data access

Audit logs can be exported as CSV from the admin UI.

### Model Access Controls

Administrators manage which AI models are available:

- **Enable/Disable models** -- Toggle model availability organization-wide
- **New provider policy** -- Control whether new model providers are automatically enabled
- **New model policy** -- Control whether new models from enabled providers are automatically activated

## Policy Enforcement

Kindo enforces policies at the platform level, not at the model level. This means:

- Policies apply uniformly regardless of which model a user selects
- Switching models does not bypass DLP, RBAC, or audit requirements
- Agent actions are governed by the same rules as interactive chat

## Compliance Support

Kindo's governance features support common compliance frameworks:

| Framework | Relevant Controls |
|-----------|------------------|
| **SOC 2** | Audit logging, access controls, encryption |
| **GDPR** | DLP, data residency (on-prem), right to erasure |
| **ISO 27001** | RBAC, audit trails, security policies |
| **NIST CSF** | Monitoring, access management, incident response |

For FedRAMP requirements, deploy Kindo on-premises in an approved cloud environment (e.g., AWS GovCloud) under your own authorization boundary.

## Next Steps

- [Configure Security Controls](/admin/security-controls/) to set up DLP and model access policies
- [Configure Tool Action Access Controls](/admin/rbac-tool-actions/) to manage which integrations and tools are available per user group
- [Set up SSO](/admin/sso/) to integrate with your identity provider
- [Set agent and department budgets](/admin/budgets/) to get an email when an agent's or a department's monthly spend reaches an amount you set
- [Learn about Agents](/features/agents/) to understand how governance applies to automated workflows

---

## Sandbox Tool Channel

Source: https://docs.kindo.ai/features/sandbox-tool-channel/

The sandbox tool channel lets a shell command running in an agent's [sandbox](/admin/faq/#what-is-a-secure-sandbox) call the agent's integration tools directly, without a model turn for each call. A script can look up a record, branch on the answer, and update another system in one command. The agent already knows this from its shell tool, so you do not have to explain the mechanics: describe the read-then-branch job and it writes the script.

:::note
The sandbox tool channel is being rolled out gradually and is available only to organizations enrolled in the rollout. Contact your Kindo representative if you want it enabled for your organization.
:::

## Two Ways to Call a Tool

From the shell, `kindo-tool` prints the tool's result as JSON on stdout, so it pipes into `jq`:

```sh
kindo-tool list
kindo-tool call linear_list_issues '{"teamId": "ENG"}' | jq .
```

From Python, `kindo_tool` is importable in any command:

```python

tools = kindo_tool.list_tools()
issues = kindo_tool.call_tool("linear_list_issues", {"teamId": "ENG"})
```

A failed call raises `kindo_tool.KindoToolError`. The CLI prints the error and exits non-zero. The script decides whether to stop or continue.

## What a Command Can Call

- The integration tools available to the conversation that are set to run automatically. Tools set to **Ask before running** are neither listed nor callable, because a running command cannot wait for approval. See [Tool Actions and Permissions](/admin/rbac-tool-actions/).
- Not the sandbox's own tools, not child-agent tools, and not Platform tools.
- `kindo-tool list` shows exactly what the current command may call.

## Limits

- The channel is open only while the command that started it runs. When the command exits, calls fail instead of hanging, and a background process that outlives the command cannot call tools.
- Each command may make up to 100 tool calls. Further calls fail.
- The command's timeout bounds every call it makes. The default is 60 seconds and the maximum is 300. The agent can raise the timeout on a command that needs longer.
- Requests travel on the command's stderr. A command that redirects stderr, for example with `2>/dev/null`, disables the channel. Redirect stdout instead.

## Permissions and Auditing

No credential enters the sandbox. Kindo executes each call on the agent's behalf, under the same permissions as a tool call the model makes itself, and records it in the audit log the same way. A command cannot reach a tool the agent could not call directly.

## What the Conversation Records

The shell command's result reports how many tool calls it made. The individual calls appear in the audit log, not as separate entries in the conversation. For [Script steps](/features/script-steps/#call-tools-from-a-script), each call is also recorded in the run.

## Next Steps

- [Script Steps](/features/script-steps/)
- [Working with Large Context](/best-practices/working-with-large-context/)
- [Tool Actions and Permissions](/admin/rbac-tool-actions/)

---

## Skills

Source: https://docs.kindo.ai/features/skills/

:::note[Beta]
Skills are in beta and appear only for organizations enrolled in the rollout. Contact your Kindo representative if you want them enabled for your organization.
:::

Skills are reusable instruction packages that help Kindo handle a specific task consistently. A skill contains a required `SKILL.md` file with a name, a description, and instructions. It can also include supporting files such as reference material, templates, or scripts.

This guide covers skills you create and manage yourself.

## Create a Skill in Chat

Ask Kindo to turn a repeatable set of instructions into a skill. For example:

```text
Create a skill that turns meeting notes into a concise summary with decisions, action items, and open questions. Do not invent details that are not in the notes.
```

Review the drafted `SKILL.md`, make any changes you need, then ask Kindo to save it. You can find the saved skill in **Skills**.

To write the package yourself, follow the steps below.

## Create a Skill Package

Create a folder for each skill. Put one `SKILL.md` file at the root of that folder. File paths inside the package must be relative to the folder.

### Write `SKILL.md`

Start with YAML frontmatter between `---` lines. The `name` and `description` fields are required. Use a lowercase, hyphen-separated name with up to 64 characters.

```md
---
name: meeting-notes
description: Turn meeting notes into a concise summary with decisions and next steps.
---

# Meeting notes

Summarize the supplied notes in this order:

1. Key decisions
2. Action items, including an owner when one is named
3. Open questions

Do not invent decisions, owners, or dates that are not in the notes.
```

Write instructions that state the task, the expected output, and important boundaries. Specific instructions are easier to reuse than broad requests such as “help with meetings.”

### Add Supporting Files When Useful

Keep optional files in the same folder, for example:

```text
meeting-notes/
├── SKILL.md
└── references/
    └── team-terms.md
```

Reference supporting files by their relative paths in `SKILL.md` when the instructions need them. A package can contain up to 64 files. `SKILL.md` can be up to 64 KiB, each other file up to 256 KiB, and the complete package up to 2 MiB.

## Upload a Skill

Each single-skill package must contain exactly one root `SKILL.md`. Kindo rejects unsafe paths, duplicate paths that differ only by letter case, packages that exceed the limits, and frontmatter that does not meet the required format.

## Inspect and Use a Skill

Select a skill in the Skills library to view its description, instructions, and files. Select a file to preview it when it is text. Markdown files render as Markdown; a binary file or a file that is too large to preview can still be downloaded with **Export**.

Use skills in AI Chat by asking about the task the skill describes. You can also attach a skill you own to an agent you can edit:

For more on creating an agent, see [Creating and Managing Agents](/features/creating-agents/).

## Update a Skill

To publish a new version, open the skill and select **Upload new version**. Choose a single folder whose root `SKILL.md` has the same `name` as the existing skill.

The skill's creator may view its version history, restore an earlier version, or delete it.

Uploading a new version replaces the complete package. Include every file that the new version needs; files omitted from the uploaded folder are not part of the new version. The skill keeps its name and version history, and the library opens the new version after upload.

If a normal upload uses a name that already exists, Kindo reports the conflict and offers **Replace existing skill?**. Review the package name before confirming, because replacement uses the name in `SKILL.md`.

## Version History and Restore

Select **Version history** on a skill to view its versions. Open a prior version to inspect its instructions and file list.

To return to an earlier version, select **Restore this version** and confirm. Kindo creates a new current version with the earlier version’s content; it does not remove the versions already in history.

## Export or Delete a Skill

Select **Export** on a skill to download its package as a ZIP archive. Export before making a significant change or deleting a skill if you want a local copy.

Select **Delete** and confirm to remove a skill from your library. You cannot undo deletion from the Skills library.

## Troubleshooting

| Problem | What to check |
| --- | --- |
| Upload cannot find a skill | Select the package folder itself, and make sure one root `SKILL.md` is inside it. |
| Upload rejects the name or description | Check that frontmatter is valid YAML, `name` is lowercase and hyphen-separated, and both required fields have values. |
| Upload exceeds a limit | Reduce the number of files or their sizes. The package limit includes `SKILL.md` and all supporting files. |
| A replacement is blocked | Upload a single folder and make sure its `SKILL.md` name matches the skill you opened. |
| A file will not preview | Use **Export** to download the package; binary files and large files are not previewed in the browser. |

## Next Steps

- [Create and manage agents](/features/creating-agents/)
- [Learn about AI Chat](/features/ai-chat/)
- [Run a skill's script as an agent step](/features/script-steps/)

---

## Agent Script Steps

Source: https://docs.kindo.ai/features/script-steps/

:::note[Beta]
Script steps are in beta and appear only for organizations enrolled in the rollout. Contact your Kindo representative if you want them enabled for your organization.
:::

A Script step runs a Python script from one of the agent's attached [skills](/features/skills/). No model is involved unless the script asks for one: the step runs the script in the agent's sandbox, reads the result the script declares, and moves the run on. Use it for work that should happen the same way every time, such as syncing records, transforming a webhook payload, or calling an integration in a loop.

## Add a Script Step

| Setting | What it does |
| --- | --- |
| **Skill** | The attached skill the script comes from. The step runs the skill's latest version, and the run records the exact content that ran. |
| **Script** | A relative `.py` path inside the skill package. Python is the only supported language. |
| **Tools** | Read-only. Scripts run with the tool servers enabled in the agent's **Tools** section. |
| **Timeout (seconds)** | Wall-clock limit for the script, from 1 to 900 seconds. Defaults to 120. |
| **Agent follow-up** | Lets the script hand its result to the agent for a model turn. Off by default. See [Agent follow-up](#agent-follow-up). |

A skill that a Script step runs cannot be detached from the agent until the step is removed or pointed at another skill. The agent's organization needs a default chat model even with **Agent follow-up** off; without one the step fails before the script starts. A Script step never retries: scripts can call tools with side effects, so a step that fails is reported, not run again.

## How a Script Runs

- Kindo runs `python3 <script path>` in a fresh working directory inside the run's sandbox. The skill's files are staged at their package-relative paths, so a script can import its sibling modules.
- Only text files in the skill package are staged. Binary files are skipped.
- The `kindo_script` helper module is importable from any staged path. Only the Python standard library is guaranteed to be installed.
- Network access follows your organization's **Sandbox Network Access** setting. See [Tool Actions and Permissions](/admin/rbac-tool-actions/).
- A script still running when the timeout expires is killed.
- Files the script writes outside its working directory stay in the run's sandbox for the rest of the run, so later steps that use the sandbox can read them.

## Read the Input

```python

run_input = kindo_script.read_input()
trigger_data = run_input["triggerData"]
messages = run_input["messages"]
```

`read_input()` returns the run's input as a dictionary, or `None` when it is unavailable. It holds what the run started with under `triggerData` and the run's conversation so far under `messages`. Ignore keys you do not recognize; new ones may be added.

### What the run started with

| How the run started | `triggerData` |
| --- | --- |
| Integration Event trigger | The event body Kindo received. |
| Direct Webhook URL trigger | The request body. |
| Started by a parent agent, or from a chat | The text the parent forwarded, as a string. |
| Run manually, on a schedule, or through the API | `null`. Input values sent through the API are agent inputs, not the trigger data. |

`payload` holds the same value as `triggerData` and is deprecated. Read `triggerData`.

### The conversation so far

`messages` lists the run's messages, oldest first. Each agent step adds a user message describing the step and an assistant message holding its result, so the output of an earlier step is in an assistant message. The first step's user message begins with the run's trigger or parent context, then the step's own text.

| Key | Type | Meaning |
| --- | --- | --- |
| `id` | string | The message's identifier. The Conversations API returns it with the `msg_` prefix as the id of the message's first item; later items of an assistant message add a numbered suffix, and tool calls are keyed by `call_id`. |
| `index` | integer | The message's position in the conversation, starting at 0. |
| `role` | string | `"user"` or `"assistant"`. |
| `createdAt` | string | When the message was recorded, in ISO 8601. |
| `step` | object or `null` | The step the message belongs to, as `{"number": 1, "name": "Fetch incidents"}`. `number` is an integer and `name` is a string or `null`. The value is `null` for a message outside any step, such as one sent in the run's chat after its steps finished, or every message of a conversation that is not an agent run. |
| `forgotten` | boolean | `true` when the agent's context management has summarized this message out of the model's view. The message is included in the messages list; the summary that replaced it is not included. |
| `parts` | array of objects | What the message holds, in order. See the table below. |
| `truncated` | boolean | Present, as `true`, when parts were dropped to fit the message's size limit. Parts are dropped from the start of the message, so the ones it produced last are kept. |

Each part carries `type` and the keys for its kind:

| Key | Type | Meaning |
| --- | --- | --- |
| `type` | string | `"text"`, `"reasoning"`, `"tool-<name>"` for a built-in tool, `"dynamic-tool"` for a tool from a connected tool server, or another kind. A tool part is one that has `toolCallId`; a part of any other kind carries only its `type`. |
| `text` | string | The text of a `text` or `reasoning` part. |
| `toolCallId` | string | Tool parts. Identifies the call. |
| `toolName` | string | `dynamic-tool` parts. The tool's name. |
| `state` | string | Tool parts. Where the call got to, such as `"output-available"` or `"output-error"`. |
| `input` | JSON value | Tool parts. What the tool was called with. |
| `output` | JSON value | Tool parts. The result, present when the call succeeded. Check its type before indexing into it: the agent's context management can replace an older call's `output` with a placeholder string, and such a part is marked `truncated`. |
| `errorText` | string | Tool parts. The error, present when the call failed. |
| `truncated` | boolean | Present, as `true`, when the part was cut to fit its size limit, or when context management replaced its `output`. A cut tool part keeps every key except `input` and `output`, and only the start of its `errorText`. A cut text part keeps the start of its `text`. |

A previous LLM step's answer is the text of the latest assistant message:

```python
assistant_messages = [message for message in messages if message["role"] == "assistant"]
previous_answer = "".join(
    part["text"] for part in assistant_messages[-1]["parts"] if part["type"] == "text"
)
```

Two size limits keep the input bounded, each approximate by what JSON escaping adds: about 64,000 characters for a message, which also bounds any single part, and about 128,000 for `messages` as a whole. A part over the message limit is cut as its `truncated` row describes. A message over its limit first cuts the `input` and `output` of its largest tool parts, largest first, marking each one `truncated`, so every call stays listed with its `state`; only if that is not enough does it drop parts from its start. A message always keeps its last part, cut to fit if it must be. When the conversation outgrows the limit for `messages` as a whole, it holds the newest messages that fit and leaves out the older ones. `messageCount` is how many messages with content the conversation holds, including any left out here, so a `messageCount` larger than the length of `messages` means older messages were left out. A message's position is its `index`, not its place in `messages`.

## Declare the Result

```python

kindo_script.declare_result("success", detail="Synced 12 records.")
```

Call `declare_result` before the script exits. The last call wins. A script that exits with code 0 without declaring anything is a success.

| Argument | Type | Meaning |
| --- | --- | --- |
| `status` | `"success"` or `"error"` | The outcome. A declared `error` completes the step; it is an outcome, not a failure. |
| `detail` | string | Free text describing the outcome. Shown in the run and passed to the agent on follow-up. |
| `guidance` | string, optional | Steering for the agent's follow-up turn. |
| `infer` | boolean, default `False` | Ask the agent to follow up on the result. Honored only when **Agent follow-up** is on. |
| `halt_run` | boolean, default `False` | Cancel the run once this step completes. Later steps never run. |

`declare_result` raises `ValueError` for a status other than `success` or `error`, and `TypeError` when `infer` or `halt_run` is not a boolean.

### Detail and guidance limits

Kindo keeps the last 8,192 characters of `detail` and of `guidance`. A longer value loses its beginning, and a leading `…` marks that this happened. Only the truncated text is stored. Write a summary, or a pointer to output stored elsewhere, rather than a full log.

### How Kindo reads an exit

| What the script did | Status | Detail |
| --- | --- | --- |
| Declared a valid result, with any exit code | As declared | As declared |
| Declared nothing and exited 0 | `success` | stdout |
| Declared nothing and exited non-zero | `error` | stderr, then stdout, then "Script failed without output." |
| Wrote a result Kindo could not parse | `error` | stderr, then stdout, then "Script failed without output." |
| Was killed at the timeout | `error` | "Script exceeded its time limit." followed by the end of stderr or stdout |

A timeout is an error whatever the script declared. Undeclared `infer` and `halt_run` are `False`. Write diagnostics to stderr: it is what becomes the detail when a script fails without declaring one, and a Python traceback lands there on its own.

### Agent follow-up

With **Agent follow-up** on, a script that declares `infer=True` hands its result to the agent. The agent receives the declared status, detail, and guidance, along with every tool call the script made, and runs a model turn with the agent's tools on your organization's default chat model. The model's reply becomes the step's response. With the toggle off, `infer=True` is ignored and the step completes with the declared result.

```python
kindo_script.declare_result(
    "error",
    infer=True,
    detail="Upstream returned 404 for 3 of 12 records.",
    guidance="Retry the failed records with the fallback endpoint.",
)
```

### Halting the run

A script that declares `halt_run=True` completes its step and then cancels the run. Steps after it never run, and the run shows a **Run halted** marker. Declared together with `infer=True`, the follow-up turn runs first, then the run halts.

For [objective evaluation](/apis/agents/runs/), a Script step's verdict follows its status: `success` is satisfied and `error` is not satisfied. Because `halt_run` cancels the run, a run halted by a script reports an aggregate result of `partial` on the Agents API, with the per-step verdicts intact.

## Call Tools from a Script

Scripts use the [sandbox tool channel](/features/sandbox-tool-channel/), the same one shell commands use: the `kindo_tool` module and the `kindo-tool` CLI, with the same stderr rule, the same ceiling of 100 calls, counted per step run, and the same rule that only tools set to run automatically are callable. Script steps always have the channel and need no separate enrollment in its rollout. Three things differ for Script steps:

- The tool set comes from the tool servers enabled in the agent's **Tools** section rather than from the conversation.
- The channel stays open for the whole script run, bounded by the step's timeout rather than by a single command's.
- Each call is recorded in the run as its own entry beside the script's execution, as well as in the audit log.

```python

issues = kindo_tool.call_tool("linear_list_issues", {"teamId": "ENG"})
```

## What the Run Records

Each Script step adds two messages to the run's conversation: a message naming the skill and script, and a response holding the execution. The execution shows the declared fields under **RESULT** and the free text under **DETAIL**. Each tool call the script made appears alongside it.

- A run stopped while a script is running kills the script. The response is marked **Generation Stopped**, and the execution reads "Tool execution was interrupted before completion".
- Version history captures the skill, script path, timeout, and Agent follow-up setting. Duplicating or restoring an agent keeps its Script steps. Importing an agent definition attaches each pinned skill to the new agent, and is refused when the importer cannot attach that skill.

## Next Steps

- [Skills](/features/skills/)
- [Creating and Managing Agents](/features/creating-agents/)
- [Agent Runs API](/apis/agents/runs/)

---

## Memory

Source: https://docs.kindo.ai/features/memory/

## Overview

When memory is enabled, Kindo remembers useful context from your conversations — notes from what you discussed, plus facts you ask it to remember — and recalls the relevant pieces in later conversations so you do not have to repeat yourself.

For step-by-step walkthroughs, see the [Use Memory](/quickstarts/memory/) quickstart.

:::note[Memory vs. Conversation History]
Memory — the **Memory Engine** — is different from a conversation's own history. Within a single conversation, the model already sees everything said so far. Memory carries context *across* conversations.
:::

### How Memory Works

**Capture** — Kindo keeps notes from your conversations, and the assistant saves specific facts when you ask it to remember something (or removes them when you ask it to forget). Memory is platform-authored: there is no manual entry form — everything stored comes from your conversations.

**Recall** — In later conversations, Kindo searches your stored memories and provides the relevant ones to the model as context.

**Control** — Memory is transparent and user-controlled. Every stored memory is visible on the **User Memory** page in your personal settings, where you can review, edit, or delete any of them (or delete all of them). A per-user **Memory** toggle in the chat settings menu turns the whole feature off for you.

:::note[Memory vs. Agent File Persistence]
Sandboxes and knowledge stores carry *files and state* for agents; memory carries *facts* for conversations. See [Memory and Persistence Patterns](/best-practices/memory-and-persistence/) for the file-persistence options.
:::

## The Two Kinds of Memory

Kindo provides two kinds of memory. They never overlap: each conversation uses one or the other, never both.

|  | User Memory | Agent Memory |
| --- | --- | --- |
| **Scoped to** | You, within your organization | A single agent |
| **Applies in** | Chats — direct conversations with a model | Conversations with that agent |
| **Who can see it** | Only you | Everyone who uses the agent |
| **Shared?** | Never — private to your use of the platform | Yes — shared across all runs and all users of the agent |
| **How enabled** | On when memory is available for your org; opt out with the Memory toggle | Consent-gated: both the org admin and the agent's author must opt the agent in |

### User Memory

User Memory is scoped to **you** within your organization. It is private — no other user can see or search your memories. Organization administrators can review activity through audit logs.

User Memory applies **only in chats**: direct conversations with a model (Ask and Actions modes). It does not apply when you converse with an agent.

You manage it yourself:

- **View, edit, delete** individual memories — or delete all — from the **User Memory** page in your personal settings.
- **Turn it off** with the Memory toggle in the chat settings menu. The preference persists across sessions.

### Agent Memory

Agent Memory is scoped to **an agent**. Where User Memory is private to one person, an agent's memory is shared across **all runs and all users of that agent** — a fact captured while one person works with the agent can be recalled when a different person uses it later.

Because that crosses the usual boundary between users' sessions, Agent Memory is **consent-gated**: it stays off unless both the organization administrator and the agent's author explicitly opt the agent in — enabling requires both to acknowledge the shared-memory model.

:::note[Why sharing matters]
Sharing is what makes Agent Memory useful — an agent can accumulate knowledge about the job it does rather than starting cold with every user. But keep in mind: anything a memory-enabled agent stores during your conversation can be recalled when a colleague uses the same agent later.

Do not share something with a memory-enabled agent that the agent's other users should not see. Your own User Memory stays out of it entirely — an agent conversation never reads or writes your User Memory.
:::

When Agent Memory is on for the agent you are talking to, the chat settings menu shows this: an added read-only **Agent Memory** row with a short reminder that the memory is shared, and the menu's trigger reads "MEMORY ON" so the state is visible without opening the menu. Your per-user Memory toggle still appears alongside it when User Memory is available in your organization — disabled during the agent run, since an agent conversation never uses your User Memory.

![Agent Configuration page — the Agent Memory section with its toggle and shared memory table](../../../assets/docs/memory/agent-memory-setting.png)

## How Memory Is Scoped

Every memory belongs to exactly one scope: your organization plus either a user (User Memory) or an agent (Agent Memory). Memories never cross organizations, never cross users, and never cross agents.

Each conversation reads and writes **exactly one** memory space:

- A **chat** uses your User Memory.
- An **agent conversation** uses that agent's Agent Memory (when enabled) — never your User Memory.

There is no conversation in which both apply. This is why the Memory toggle in the chat settings menu is disabled while you are working with an agent: user memory is not available in agent conversations.

## Memory Tools

When memory is enabled, the model has four memory tools. When the model invokes one, the call appears in the conversation like any other tool use; automatic recall and capture happen in the background:

| Tool | Kind | What it does |
| --- | --- | --- |
| `memory_search` | Read | Finds stored memories relevant to a query |
| `memory_get` | Read | Reads a specific memory document |
| `memory_store` | Write | Saves a fact. Reports a duplicate if a near-identical memory already exists instead of writing a second copy |
| `memory_forget` | Write | Removes a memory — by direct reference, or by search query when exactly one confident match is found |

The tools operate only on the conversation's single memory scope.

## Common Tasks

## Configuration

Memory is on by default. Organization administrators can turn it off, as described below.

### Organization Level

Organization administrators can turn memory on or off for the entire organization under **Settings → Organization → Agent Runtime**. When the organization toggle is off, memory is inert for everyone: no capture, no recall, no memory tools.

### User Level

Each user can opt out individually with the Memory toggle in the chat settings menu, and can manage stored memories from the **User Memory** page in personal settings. A user's opt-out affects only that user.

### Agent Level

Agent Memory is additionally gated per agent by the dual consent described above — both the org admin and the agent author must opt in.

:::note
**Key principle:** Memory is active in a conversation only when every applicable switch is on.
:::

![Settings → Organization → Agent Runtime — User Memory and Agent Memory toggles](../../../assets/docs/memory/org-memory-setting.png)

## Verification

To confirm memory is working for you, save a distinctive fact and check that a fresh chat recalls it.

Recall is relevance-based: Kindo searches your stored memories and provides the ones related to the current topic, not all of them.

## Troubleshooting

**No Memory toggle appears in the chat settings menu**

An administrator turned memory off for your organization, or you turned off your own Memory toggle. The User Memory page in your personal settings is visible either way and notes when the feature is unavailable.

**The Memory toggle is greyed out in a conversation**

You are conversing with an agent. This is expected: User Memory applies only in chats, and the single-partition rule means an agent conversation never touches your User Memory.

**Something wasn't recalled in a later conversation**

Recall surfaces only the stored memories relevant to the current topic. For facts that matter, ask the assistant explicitly to remember them, and confirm your Memory toggle is on.

**A deleted memory still shows up in the current conversation**

Deleting a memory removes it from storage, but a conversation that already recalled it keeps its existing context. Later conversations will not recall it.

**The assistant reports a duplicate when saving**

`memory_store` declines to write when a near-identical memory already exists. Review the existing memory on the User Memory page; edit it there if it needs updating.

## FAQ

**Does memory change what the model can see inside one conversation?**

No. Within a single conversation the model already sees the whole conversation. Memory is about carrying context *across* conversations.

**Can I add a memory directly, without a conversation?**

No. Memory is captured from conversations. To add a fact, ask the assistant to remember it.

**Can my administrator read my memories?**

Your User Memory is private — no other user can see or search it. Administrators can review activity through audit logs and other administrative tools.

**Does turning the Memory toggle off delete my memories?**

No. The toggle stops capture and recall for your User Memory; stored memories remain on the User Memory page until you delete them.

**What happens to my User Memory in agent conversations?**

Nothing. Agent conversations never read or write your User Memory.

**Is my memory shared with anyone?**

User Memory is never shared with other users. Agent Memory is shared by design across the users of that agent — and only exists for agents that were explicitly opted in by both the administrator and the agent's author.

---

## Secrets Vault

Source: https://docs.kindo.ai/features/secrets-vault/

The Secrets Vault is a secure, personal store for sensitive values — API keys, access tokens, and other credentials — that your agents need when calling external APIs. Secrets are encrypted at rest, and once saved, their values are never displayed again: not in the UI, not in run output, and not to anyone you share an agent with.

## Managing your secrets

Open **Settings > Secrets Vault** (or go directly to [app.kindo.ai/?settings=secrets-vault](https://app.kindo.ai/?settings=secrets-vault)). Every Kindo user has a personal vault; secrets are owned by you, not shared across your organization.

From the vault you can:

- **Add a secret** — give it a label (unique within your vault) and paste the value. The input is masked as you type, with a toggle to reveal it before saving.
- **Rename a secret** — edit the label inline. The stored value is unchanged.
- **Delete a secret** — if the secret is referenced by any agent API Action Steps, the confirmation dialog lists each affected agent with a link to it. Deleting removes the referencing header and parameter fields from those steps.

Secrets are write-only: there is no way to view a stored value after saving it. To change a secret's value, delete it and create a new one, then re-select it in the steps that used it.

## Using secrets in agents

Secrets are consumed by **API Action Steps** in the agent builder. When configuring a request header or query parameter, choose **Secret** as the value type and pick one of your secrets from the dropdown.

Common uses:

- **Authentication headers** — select a scheme (**Bearer** or **Basic**) and a secret, and Kindo builds the `Authorization` header for you.
- **Custom headers** — for example, an `X-API-Key` header whose value is a secret.
- **Query parameters** — for APIs that pass credentials as URL parameters.

Secrets can be used in headers and query parameters only. The endpoint URL and request body accept text or dynamic values, not secrets.

At run time, Kindo decrypts the secret and sends it with the request. Everywhere the request is shown — run history, step output visible to the model, and audit logs — the value is replaced with the literal text `SECRET`, so a header renders as `Authorization: Bearer SECRET`.

## Secrets and shared agents

When you share an agent that uses your secrets:

- Users you share it with can **run** the agent, and their runs use your secrets — but they can never view the values or edit the API Action Steps. In the builder, they see a `CREATOR'S SECRET` placeholder instead of your secret's label.
- When someone **duplicates** your agent, your secrets are not copied. The duplicated steps contain a `[SECRET_PLACEHOLDER]` marker, and the builder shows a warning on each affected step until the new owner replaces the placeholders with secrets from their own vault.

Before sharing an agent that references secrets, Kindo shows a confirmation summarizing exactly this behavior.

## Auditing

Creating, renaming, and deleting a secret each produce an audit log event that records the secret's label — never its value. API requests made by agents appear in the audit log with secret values redacted.

---

## Deploy & Operate

Source: https://docs.kindo.ai/deploy/

Self-Managed Kindo (SMK) is the Kindo platform packaged for deployment inside your own Kubernetes cluster. Install, upgrade, and operate it with `kindo-cli`.

## What SMK gives you

SMK runs the full Kindo platform inside your own environment, so you control where it runs, what it can reach, and which models it uses. It includes the same features as Kindo SaaS.

| Need                         | What SMK gives you                                                                        |
| ---------------------------- | ----------------------------------------------------------------------------------------- |
| Data residency               | All traffic and storage stay inside your network and region.                              |
| Regulatory compliance        | Deploy into environments already certified for PCI-DSS, GDPR, HIPAA, FedRAMP, or similar. |
| Private model hosting        | Serve models from your own GPUs, so model traffic stays inside your network.              |
| Internal identity and audit  | Audit logs, metrics, and SSO integration stay inside your environment.                    |

:::note
Kindo SaaS ships continuously; SMK ships through scheduled releases.
:::

## The deployment journey

Upgrading from 2026.07? Follow [Upgrade from 2026.07 to 2026.09](/deploy/upgrade-2026-09/).

---

## Plan & Provision Infrastructure

Source: https://docs.kindo.ai/deploy/provision-infrastructure/

Provision the cluster and services on this page before you install Kindo. Kindo runs on any conformant Kubernetes cluster, with backing services that are managed or self-hosted. When everything is in place, confirm it with the [prerequisites checklist](#8-prerequisites-checklist).

Kindo requires every item on this page unless it is marked recommended or optional.

## 1. Choose a size

Choose the size that matches your expected usage.

### Usage

| Size   | Active users | Agent runs per day |
| ------ | ------------ | ------------------ |
| Medium | 50 to 200    | About 1,500        |
| Large  | 200 to 1,000 | About 5,000        |

### Cluster capacity

| Component               | Medium                        | Large                          |
| ----------------------- | ----------------------------- | ------------------------------ |
| Cluster nodes (total)   | 12 nodes: 96 vCPU, 192 GB RAM | 20 nodes: 320 vCPU, 640 GB RAM |
| &emsp;Application nodes | 6 × 8 vCPU, 16 GB RAM         | 10 × 16 vCPU, 32 GB RAM        |
| &emsp;Sandbox nodes     | 6 × 8 vCPU, 16 GB RAM         | 10 × 16 vCPU, 32 GB RAM        |
| Block storage           | 1.5 TiB                       | 3 TiB                          |

### Required service sizes

| Component             | Medium           | Large             |
| --------------------- | ---------------- | ----------------- |
| PostgreSQL: main      | 2 vCPU, 8 GB RAM | 4 vCPU, 16 GB RAM |
| PostgreSQL: auxiliary | 2 vCPU, 8 GB RAM | 2 vCPU, 8 GB RAM  |
| Redis                 | 3 GB RAM         | 6 GB RAM          |
| RabbitMQ              | 2 vCPU, 8 GB RAM | 4 vCPU, 16 GB RAM |

### Sizing notes

- **Node counts** are the maximum each node group needs. With a cluster autoscaler, set them as the node group maximums.
- **Sandbox nodes** run agents' tools and scripts. Add sandbox nodes if you expect more agent runs.
- **Block storage** comes from your StorageClass and grows as people keep persistent agent workspaces. Volumes can grow, where the StorageClass supports it, but never shrink.
- **Required services** you run in the Kindo cluster add to the cluster capacity. Add their resources, for every replica, to the totals.

Start from these sizes, monitor usage, and adjust as it grows; see [Scaling and Tuning](/deploy/scaling-and-tuning/).

## 2. Kubernetes cluster

| Attribute                     | Requirement                                                                                                                                               |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Version                       | 1.32 or higher                                                                                                                                            |
| Networking                    | Any conformant CNI                                                                                                                                        |
| Storage                       | Dynamic volume provisioning, with a default StorageClass that provisions ReadWriteOnce volumes                                                            |
| Ingress                       | An ingress controller (NGINX, Traefik, AWS Load Balancer Controller, or equivalent); `kindo-cli` asks for its class name                                  |
| TLS                           | cert-manager, or certificates you provision yourself; see [TLS certificates](#tls-certificates)                                                           |
| RBAC                          | Enabled                                                                                                                                                   |
| Metrics                       | `metrics-server` installed                                                                                                                                |
| External Secrets Operator     | Kindo installs its own. If the cluster already runs one, it must serve `external-secrets.io/v1` (ESO 0.17 or later), or the install stops                 |
| Volume attach limit           | Your CSI driver must allow at least 10 attached volumes per sandbox node at Medium and 20 at Large. If your instance type allows fewer, add sandbox nodes |
| Availability zones            | Run nodes in every zone your StorageClass provisions volumes in. A pod with a volume restarts only in its volume's zone                                   |
| Sandbox node group (optional) | A dedicated, tainted node group keeps agent activity off the application nodes. Set a matching sandbox node selector and toleration at install            |

### Provider notes

- **AWS Load Balancer Controller with a non-VPC CNI** (such as Calico or Cilium): configure services behind the controller as `NodePort` and use `target-type=instance`, or use an in-cluster ingress controller such as NGINX or Traefik.

## 3. Required services

Kindo connects to these services. Run them as managed services, on your own servers, or in the cluster.

### PostgreSQL

| Attribute              | Requirement                       |
| ---------------------- | --------------------------------- |
| Version                | 17.0 or higher (17.4 recommended) |
| Concurrent connections | 200 or more                       |

Provision a main instance, an auxiliary instance, and, recommended, a dedicated instance for Hatchet, Kindo's task scheduler. Set the Hatchet instance as `postgres.adminHatchet` in `environment-bindings.yaml`; without it, Hatchet uses the auxiliary instance. The installer creates the databases.

#### PostgreSQL settings for Hatchet

Apply these settings to the instance that hosts the `hatchet` database, at every size:

| Parameter                         | Recommended |
| --------------------------------- | ----------- |
| `autovacuum_max_workers`          | `10`        |
| `autovacuum_vacuum_scale_factor`  | `0.1`       |
| `autovacuum_analyze_scale_factor` | `0.05`      |
| `autovacuum_vacuum_threshold`     | `25`        |
| `autovacuum_analyze_threshold`    | `25`        |
| `autovacuum_vacuum_cost_delay`    | `10`        |
| `autovacuum_vacuum_cost_limit`    | `1000`      |

Preflight warns about Hatchet settings that differ from these. Fix them before you continue the install.

#### Provider notes

To apply the Hatchet settings:

- **AWS RDS / Aurora PostgreSQL:** create a custom DB parameter group, set the parameters, and attach it to the Hatchet instance.
- **Google Cloud SQL:** set them as database flags on the Hatchet instance. Changing `autovacuum_max_workers` requires an instance restart.
- **Azure Database for PostgreSQL:** set them as server parameters on the Hatchet server.
- **Self-managed PostgreSQL:** set them in `postgresql.conf` and reload. Changing `autovacuum_max_workers` requires a restart.

### Redis

| Attribute              | Requirement                                             |
| ---------------------- | ------------------------------------------------------- |
| Version                | 7.0 or higher (7.2 recommended)                         |
| Concurrent connections | 100 or more                                             |
| Mode                   | **Standalone: a single primary, no shards or replicas** |

To confirm the mode, check that this command returns `redis_mode:standalone`:

```bash
redis-cli INFO server | grep redis_mode
```

#### Provider notes

- **AWS ElastiCache:** Cluster Mode Disabled, with `num_node_groups = 1` and `replicas_per_node_group = 0`.
- **Azure Cache for Redis:** Basic or Standard tier (single node, non-clustered).
- **Google Cloud Memorystore:** Basic tier.

### RabbitMQ

| Attribute         | Requirement    |
| ----------------- | -------------- |
| Version           | 3.13 or higher |
| Disk              | 20 GB minimum  |
| Management plugin | Enabled        |

### S3-compatible object storage

Use any store that serves the S3 API, managed or self-hosted. Create a private bucket for user file uploads, such as `kindo-uploads`, with server-side encryption and public access blocked.

If the store runs inside the cluster, users' browsers cannot reach its cluster-local address to download files. Publish it on its own hostname:

1. Expose the store at a dedicated HTTPS hostname with a valid certificate and no path prefix, such as `https://s3.kindo.company.com`. It must serve path-style requests (`https://s3.kindo.company.com/<bucket>/<key>`), and any proxy in front of it must forward the `Host` header unchanged.
2. In `environment-bindings.yaml`, set `storage.endpointUrlPublic` to that hostname, and keep `storage.endpointUrl` on the cluster-local address.

#### Provider notes

- **Azure Blob Storage:** it does not serve the S3 API, so put an S3-compatible gateway in front of it. If the gateway is s3proxy, use 4.0.0 or later; earlier versions break multipart uploads.

### Email

Kindo needs an SMTP relay to send sign-in codes and other email. Use your own SMTP server or a provider such as Amazon SES, SendGrid, or Mailgun.

Have the relay's host and the from address ready for the install; the port defaults to 587. A username and password are optional:

- **Authenticated relay:** provide both. Kindo authenticates with them.
- **IP-allowlisted relay:** leave both unset, and allow the cluster's outbound addresses on the relay. Kindo then never attempts SMTP authentication, even when the relay offers it. If you keep `SMTP_USER` and `SMTP_PASSWORD` in an [external secrets store](/deploy/external-secrets-store/), delete them there too: a value in the store takes precedence over the contract. This suits an internal relay such as an Exchange receive connector that accepts anonymous mail from known addresses.

`kindo upgrade --apply` sends a preflight test email from the from address to `operatorEmail`, and `kindo config validate --preflight --test-email` does the same before you install. Amazon SES rejects it, and later every sign-in code, unless the sender (`smtp.fromEmail` or its domain) is a verified identity. While the account is in the SES sandbox, the recipient must be verified too; production access lifts only that recipient restriction.

If the relay offers STARTTLS, Kindo's API and task worker verify its certificate against the SMTP host. Use a host name that the certificate covers. If the relay is reachable only under a name its certificate doesn't cover, such as an internal `.local` name, set `smtp.tlsServername` to a name the certificate does cover.

### AI models

Kindo needs at least one model endpoint: a cloud provider API, a model server you host, or both. A self-hosted model runs on GPU servers, in this cluster or anywhere on your network the cluster can reach. Choose your models and size any GPUs with [Prepare AI Models](/deploy/prepare-ai-models/) before you provision.

## 4. Network

### DNS subdomains

Pick a parent domain you control; the examples use `kindo.company.com`. Your ingress load balancer serves every hostname below. Create a DNS record for each, or one wildcard record for `*.kindo.company.com`. Tools such as external-dns can create the records for you.

| Subdomain               | Serves                                    |
| ----------------------- | ----------------------------------------- |
| `app.`                  | The Kindo app                             |
| `superadmin.`           | The superadmin dashboard                  |
| `api.`                  | The Kindo API and inbound webhooks        |
| `integrations-api.`     | The integrations API                      |
| `integrations-connect.` | Sign-in pages for connecting integrations |
| `hatchet.`              | The task scheduler's API and dashboard    |
| `unleash.`              | The feature flag service                  |
| `unleash-edge.`         | Feature flag delivery to the app          |
| `hyperdx.`              | The observability dashboard               |

If you run object storage inside the cluster, also publish its public hostname; see [S3-compatible object storage](#s3-compatible-object-storage).

When `kindo-cli` manages ingress, it creates the routes for every host. If you manage ingress yourself, print the routes and configure them as described in [Configure & Validate](/deploy/configure-and-validate/#1-publish-dns-records):

```bash
kindo ingress manifest
```

#### Inbound webhooks

Webhooks, including agent trigger URLs such as `https://api.<domain>/webhook/agent/<agentId>/<token>`, use `api.<domain>` by default. If `api.<domain>` is behind an allowlist, keep its `/webhook` path reachable from the internet, or give webhooks their own hostname:

1. Set `endpoints.webhooks: https://webhooks.<domain>` in the install contract.
2. Create a DNS record and a TLS certificate for that hostname. When `kindo-cli` manages ingress, it publishes the hostname with a route for `/webhook` only.

### TLS certificates

Use cert-manager with an ACME issuer (such as Let's Encrypt) or a private CA, or a pre-issued wildcard certificate for `*.kindo.company.com` stored as a Kubernetes Secret. `kindo-cli` references the certificate by name; it does not issue or rotate it.

### Inbound

All Kindo traffic is TCP. Open only the ingress entry points, to the internet or to your corporate network if Kindo is internal-only.

| Port | Purpose                                      |
| ---- | -------------------------------------------- |
| 443  | HTTPS: all user traffic                      |
| 80   | HTTP redirect to 443 (optional, recommended) |

### Outbound

The install and Kindo itself fail if the cluster cannot reach these destinations. Confirm them with your network team before you provision.

| Port         | Destination                                                                                     | Purpose                                    |
| ------------ | ----------------------------------------------------------------------------------------------- | ------------------------------------------ |
| 443          | `registry.kindo.ai` and other container registries, AI model providers, external object storage | Image pulls, model inference, file storage |
| 5432         | PostgreSQL                                                                                      | Database traffic                           |
| 6379         | Redis                                                                                           | Cache and streaming                        |
| 5672         | RabbitMQ                                                                                        | Message queue                              |
| 25, 587, 465 | SMTP relay                                                                                      | Email                                      |

## 5. Access and security

Access controls in your environment are the most common cause of a blocked install. Arrange these with your security team early.

- **Install identity.** The identity that runs the install needs rights to create namespaces, service accounts, role bindings, CRDs, and other cluster-scoped resources.
- **Organization guardrails.** Review policies that could block the install or the resources it creates: SCPs (AWS), organization policies (GCP), or management group policies (Azure).
- **Workload identity.** Services that call your cloud provider, such as the model gateway calling Amazon Bedrock, use workload identity: IRSA (AWS), Workload Identity (GCP), or Microsoft Entra Workload ID (Azure).
- **Container images.** Kindo pulls images from `registry.kindo.ai` with credentials Kindo provides. Allow the registry, or your internal mirror if air-gapped, in your registry allowlist and admission controllers. If you require scanned images, ask Kindo for SBOMs or a mirror-and-scan workflow.
- **Secrets store.** Choose where Kindo keeps its secrets: Kubernetes Secrets (the default), AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault. See [External Secrets Store](/deploy/external-secrets-store/). Decide who can read the `kindo-secrets-config` Secret.
- **Encryption.** For production, encrypt PostgreSQL, Redis, object storage, and Kubernetes Secrets at rest, and PostgreSQL connections in transit.

## 6. Production recommendations

For a production install, also plan for the following:

- **On-demand nodes.** Run production on on-demand nodes. Spot nodes can be reclaimed at any time, which interrupts running agents and restarts stateful services.
- **High availability.** Run PostgreSQL with streaming replication or as a managed service with automatic failover. Run RabbitMQ as a cluster of 3 or more nodes with quorum queues, or as a managed service.
- **Backups.** Take daily automated PostgreSQL backups with 7 or more days of retention. Back up Kindo's configuration as described in [Back up and restore](/deploy/operate/#back-up-and-restore).
- **Disk alerts.** Alert on disk usage on every PostgreSQL instance, especially Hatchet, and on the cluster's persistent volumes, before a volume fills.

## 7. Install host

Run the install from a bastion, jump box, laptop, or CI runner that can reach the cluster's API server. Install these tools on it:

| Tool        | Version                                                    |
| ----------- | ---------------------------------------------------------- |
| `python`    | 3.11 or higher                                             |
| `kindo-cli` | Latest release, provided by Kindo                          |
| `kubectl`   | 1.32 or higher                                             |
| `helm`      | 4.0 or higher                                              |
| `helmfile`  | 1.2 or higher                                              |
| `yq`        | 4.0 or higher (the Go implementation)                      |
| `psql`      | Optional: needed for the `kindo db` commands after install |

Then confirm that the `kubectl` context for the target cluster works and has the permissions the install needs:

```bash
kubectl cluster-info
kubectl auth can-i create namespace --all-namespaces
```

## 8. Prerequisites checklist

Each item names the team that typically owns it, so you can split the list across teams.

|     | Owner                          | Item                                                                                                                                                   |
| --- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| ☐   | Platform                       | Size chosen ([Choose a size](#1-choose-a-size))                                                                                                        |
| ☐   | Cloud Ops                      | Cluster provisioned with the required add-ons, volume attach limits, and zone coverage ([Kubernetes cluster](#2-kubernetes-cluster))                   |
| ☐   | DBA / Cloud Ops                | PostgreSQL instances provisioned and Hatchet settings applied ([PostgreSQL](#postgresql))                                                              |
| ☐   | DBA / Cloud Ops                | Redis provisioned and confirmed standalone ([Redis](#redis))                                                                                           |
| ☐   | DBA / Cloud Ops                | RabbitMQ provisioned ([RabbitMQ](#rabbitmq))                                                                                                           |
| ☐   | Cloud Ops                      | Object storage bucket created, plus a public hostname if the store runs in the cluster ([S3-compatible object storage](#s3-compatible-object-storage)) |
| ☐   | Platform                       | SMTP relay details in hand ([Email](#email))                                                                                                           |
| ☐   | Security / AppDev              | At least one model endpoint ready, with GPUs sized for any self-hosted model ([AI models](#ai-models))                                                 |
| ☐   | Networking                     | Parent domain chosen and DNS records planned ([DNS subdomains](#dns-subdomains))                                                                       |
| ☐   | Security / Networking          | TLS approach decided ([TLS certificates](#tls-certificates))                                                                                           |
| ☐   | Networking / Security          | Inbound and outbound firewall rules approved ([Inbound](#inbound), [Outbound](#outbound))                                                              |
| ☐   | Cloud Ops / Security           | Install identity, organization guardrails, and workload identity arranged ([Access and security](#5-access-and-security))                              |
| ☐   | Security                       | Registry access and credentials, secrets store, and encryption arranged ([Access and security](#5-access-and-security))                                |
| ☐   | Platform / DBA                 | On-demand nodes, high availability, backups, and disk alerts planned for production ([Production recommendations](#6-production-recommendations))      |
| ☐   | Platform                       | Install host ready ([Install host](#7-install-host))                                                                                                   |
| ☐   | Platform, Networking, Security | Capacity, network, and security plans approved                                                                                                         |

## What comes next

---

## External Secrets Store (Optional)

Source: https://docs.kindo.ai/deploy/external-secrets-store/

Connect Kindo to your organization's central secrets store to manage application passwords and API keys there. Kindo stores these secrets in your Kubernetes cluster by default; follow this page when you choose an external store.

## What you manage

Use an external store for values your organization chooses to manage centrally.

Kindo supplies values you leave out. Values added to the external store override the corresponding Kindo values.

## Set up access to your store

Kindo installs and manages its own External Secrets Operator (ESO). If your cluster already runs ESO, it must serve `external-secrets.io/v1` (ESO 0.17 or later); Kindo then uses it. This requirement applies to every backend, including `kubernetes`.

Create the authentication resources for the backend and auth mode you choose. The identity needs read access to the entries listed below. Reference the resources from the `secretsStore` block in `install-contract.yaml`.

Use the linked provider setup instructions for provider-specific steps.

| Backend                                                                                 | Auth mode                     | You create                                                                                                                               |
| --------------------------------------------------------------------------------------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| [AWS Secrets Manager](https://external-secrets.io/latest/provider/aws-secrets-manager/) | `authMode: irsa`              | The External Secrets Operator's AWS identity                                                                                             |
| AWS Secrets Manager                                                                     | `authMode: access-key`        | A Kubernetes Secret in `kindo-system` named by `credentialsSecretName`, with `access-key-id` and `secret-access-key` keys                |
| [Azure Key Vault](https://external-secrets.io/latest/provider/azure-key-vault/)         | `authMode: workload-identity` | A managed identity federated to the `kindo-secret-store` ServiceAccount in the `kindo-system` namespace; set `clientId` to its client ID |
| Azure Key Vault                                                                         | `authMode: service-principal` | A Kubernetes Secret in `kindo-system` named by `credentialsSecretName`, with `client-id` and `client-secret` keys                        |
| [Vault](https://external-secrets.io/latest/provider/hashicorp-vault/)                   | `authMethod: kubernetes`      | A Vault role bound to the `kindo-secret-store` ServiceAccount in the `kindo-system` namespace                                            |
| Vault                                                                                   | `authMethod: token`           | A Kubernetes Secret in `kindo-system` named by `tokenSecretName`, with a `token` key holding the Vault token                             |

## Create the entries

An entry is a named group of keys and values in your external store. Create these entries:

- `api-env`
- `credits-env`
- `hatchet-env`
- `integrations-reconciler-hatchet`
- `litellm-env`
- `mcp-env`
- `mcp-platform-env`
- `mcp-unified-env`
- `nango-env`
- `next-env`
- `prisma-migrations-env`
- `sandbox-env`
- `task-worker-ts-env`

You can leave application values out of these entries if you want Kindo to supply them. For AWS Secrets Manager and Azure Key Vault, create a secret whose value is the empty JSON object `{}`. For Vault, create a KV v2 secret with one placeholder key, such as `KINDO_PLACEHOLDER=1`; Vault requires at least one key.

## Common values to store

You can store credentials that your organization already manages centrally. Add a shared value to every listed entry that consumes it. Use application database URLs and credentials in the external store. Keep bootstrap PostgreSQL administrator connections and the other required infrastructure bindings in `environment-bindings.yaml`.

| Value                            | Keys                               | Store entries                                                           |
| -------------------------------- | ---------------------------------- | ----------------------------------------------------------------------- |
| PostgreSQL: Hatchet              | `DATABASE_URL`                     | `hatchet-env`                                                           |
| PostgreSQL: LiteLLM              | `DATABASE_URL`                     | `litellm-env`                                                           |
| PostgreSQL: Main                 | `DATABASE_URL`                     | `api-env`, `credits-env`, `prisma-migrations-env`, `task-worker-ts-env` |
| PostgreSQL: Main read connection | `DATABASE_READ_URL`                | `api-env`                                                               |
| PostgreSQL: Nango                | `NANGO_DATABASE_URL`               | `nango-env`                                                             |
| PostgreSQL: OpenShell            | `DATABASE_URL`                     | `sandbox-env`                                                           |
| RabbitMQ: API                    | `RABBITMQ_URL`                     | `api-env`                                                               |
| RabbitMQ: Hatchet                | `SERVER_TASKQUEUE_RABBITMQ_URL`    | `hatchet-env`                                                           |
| Redis                            | `REDIS_URL`                        | `api-env`, `credits-env`, `task-worker-ts-env`                          |
| S3 static credentials            | `AWS_ACCESS_KEY`, `AWS_SECRET_KEY` | `api-env`, `task-worker-ts-env`                                         |
| SMTP connection                  | `SMTP_URL`                         | `nango-env`                                                             |
| SMTP credentials (optional)      | `SMTP_USER`, `SMTP_PASSWORD`       | `api-env`, `task-worker-ts-env`                                         |

## Point the install contract at the store

Replace the existing `secretsStore` block in `install-contract.yaml` with the example for your backend. Each example shows one auth mode. Fill in its values, then run `kindo config validate`.

### AWS Secrets Manager

```yaml
secretsStore:
  backend: 'aws'
  region: 'us-west-2'
  authMode: 'irsa'
```

For access-key authentication, replace `authMode` with `authMode: "access-key"` and add `credentialsSecretName: "<secret-name>"`. With IRSA, `roleArn` is optional when you need to assume a different role.

### Azure Key Vault

```yaml
secretsStore:
  backend: 'azurekv'
  vaultUrl: 'https://your-vault.vault.azure.net'
  tenantId: '00000000-0000-0000-0000-000000000000'
  authMode: 'workload-identity'
  clientId: '<managed-identity-client-id>'
```

For service-principal authentication, replace `authMode` and `clientId` with `authMode: "service-principal"` and `credentialsSecretName: "<secret-name>"`.

### Vault

```yaml
secretsStore:
  backend: 'vault'
  address: 'https://vault.example.com:8200'
  path: 'secret'
  authMethod: 'kubernetes'
  role: 'kindo'
```

For token authentication, replace `authMethod` and `role` with `authMethod: "token"` and `tokenSecretName: "<secret-name>"`.

## Install or upgrade

Prepare and check the required store entries before running `kindo install --apply`. A missing entry blocks its application.

Before applying an upgrade, run:

```bash
kindo upgrade --version <target> --plan
```

The plan checks whether the store is ready and reports any required key missing from both the store and Kindo's supplied values. When the upgrade needs to install ESO, the plan reports that this check will run during `--apply`, after ESO and the store are installed. The upgrade stops before changing applications if the store check fails.

After installation, run `kindo doctor` to investigate application and store health. Continue when it reports no store or sync findings and the applications are healthy. Then complete [Configure & Validate](/deploy/configure-and-validate/). See [Operate](/deploy/operate/) for diagnosis and recovery commands.

## What changes with an external store

- `kindo config override set`, `unset`, `edit`, and `apply` refuse to run. Manage those values in your external store.
- `kindo config log-level set` and `unset` refuse to run. See [`kindo config log-level`](/deploy/operate/#kindo-config-log-level) to change the level.
- `kindo config helm-override` works with an external store.

See [Operate](/deploy/operate/) for applying configuration changes.

## Move an existing install onto an external store

## Change a value later

### Update a value your organization owns

Update the appropriate entry. For example, after updating a value in `api-env`, run:

```bash
kindo config apply --only api
```

The command waits for the sync before restarting the API. If the sync times out, it warns and restarts anyway. Run `kindo doctor`, resolve the sync finding, and rerun `kindo config apply --only api`.

### Return a key to Kindo management

Remove the key from your external store to use Kindo’s value. After the change has synced, restart the affected application to pick it up.

For example, you can use `kindo config apply --only api` to wait for the sync and restart the API. If the command reports a sync timeout, resolve it and rerun the command.

Related: [Operate](/deploy/operate/) and [Upgrade](/deploy/upgrade/#per-application-secrets-on-upgrade).

---

## Prepare AI Models

Source: https://docs.kindo.ai/deploy/prepare-ai-models/

LinkCard,
  CardGrid,
  Tabs,
  TabItem
} from '@astrojs/starlight/components';

Provide inference endpoints from cloud API providers (OpenAI, Anthropic, Gemini, Bedrock, Azure), self-hosted open-weight models with vLLM, or both. After installing Kindo, register each model from the superadmin dashboard's **Models** page. This page covers endpoint preparation and the information you need for registration.

## How models get registered

After the install:

1. Open the superadmin dashboard's **Models** page and select the **Models** tab.
2. Use the **Required models** panel to add an embedding or transcription model with its preset. To register another model, open the add-model sheet.
3. Choose the provider, enter its credentials, review the model settings, and save.
4. Open the **Feature flags** tab on the **Models** page to choose which models each feature uses.

Registration makes the model available through the endpoint you supplied. [Model Configuration](/features/models/) explains model groups and provider fallbacks.

Your job on this page is to:

1. Decide which providers/endpoints you will use.
2. Make sure each endpoint is reachable from the cluster.
3. Collect the facts each model's registration needs.

:::note
Register a model for each required role:

- **Embedding model**: registered under the serving name `embedding-generator`. Vector search and retrieval.
- **Transcription model**: registered under the serving name `transcription-generator`. Audio/voice features.

The **Required models** panel checks these roles. Also register **at least one `CHAT` model with tool-calling support** for users to select in chat and for agents to call tools.

Use the required-model presets to fill in the serving names and roles.

If any of these are missing, chat, agents, ingestion, or indexing will fail.
:::

## What to know about each model before you register it

Collect the following information before opening the add-model sheet. Credentials depend on the provider.

| Fact               | Required     | What it is                                                                                                                                                                            |
| ------------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Serving name       | yes          | The unique routing key Kindo and LiteLLM address the model by. Must match `--served-model-name` for vLLM, and must be the reserved name for a required role.                          |
| Display name       | yes          | Human-readable name shown in the UI model picker.                                                                                                                                     |
| Provider           | yes          | The LiteLLM provider, which sets the connection type and the credential fields the form asks for.                                                                                     |
| Provider display name | yes       | The provider your users see for this model: pick an existing one, or choose **New provider…** and name it. A new name can't match an existing provider in any letter case.             |
| LiteLLM model ID   | yes          | The provider-prefixed model ID LiteLLM routes with (see the prefix table below).                                                                                                      |
| Credential         | varies       | API key, endpoint URL, API version, AWS keys and region, or a service account, whichever the provider needs. See the playbooks below.                                                 |
| Context window     | yes for chat | **The model's full advertised context window**. Do not low-ball it. Kindo seeds it from the catalog when the model ID matches; a chat model with neither value nor match is rejected. |
| Max output tokens  | recommended  | The largest response the model is allowed to generate in one call.                                                                                                                    |
| Extra headers      | optional     | Enter `{"extra_headers": {...}}` in **Additional litellm_params (JSON, optional)** for headers sent with every inference request, such as an `x-api-key` gateway credential.          |
| Cost tier          | recommended  | `LOW`, `MEDIUM`, or `HIGH`, carried in the model's metadata.                                                                                                                          |
| Description / link | optional     | Surfaced in the model picker.                                                                                                                                                         |

:::caution[Set both the context window and the max output tokens]
These two values are independent and **both** must be set correctly.

- **Context window**: total tokens the model can read at once (prompt + conversation history + output). Registering a model that supports 200k or 1M tokens with a context window of 8192 will silently truncate long conversations, RAG contexts, and agent tool outputs. Always use the provider's documented limit.
- **Max output tokens**: the upper bound on tokens the model is allowed to generate in a single response. LiteLLM sends this value to the provider. Set too low and long responses, code generations, and multi-step tool calls get cut off mid-sentence; set higher than the model allows and the call is rejected.

**Rule of thumb**: context window = the provider's stated limit; max output tokens = the provider's stated max output size (not the context window size).

When a model is served by several provider endpoints, the model uses the **smallest** context window across them. See [Models with Multiple Providers](/features/models/#models-with-multiple-providers-model-groups).
:::

### Provider prefix reference

| Provider           | LiteLLM model ID prefix | Example                                              |
| ------------------ | ----------------------- | ---------------------------------------------------- |
| OpenAI             | `openai/`               | `openai/gpt-4o`                                      |
| Anthropic          | `anthropic/`            | `anthropic/claude-sonnet-4-20250514`                 |
| Google Gemini      | `gemini/`               | `gemini/gemini-2.5-pro`                              |
| Azure OpenAI       | `azure/`                | `azure/<your-deployment-name>`                       |
| AWS Bedrock        | `bedrock/`              | `bedrock/us.anthropic.claude-sonnet-4-20250514-v1:0` |
| Self-hosted (vLLM) | `hosted_vllm/` or `openai/` | `hosted_vllm/deephat-v3`, `openai/deephat-v3`    |

:::note
Self-hosted vLLM models can use the `hosted_vllm/` prefix, LiteLLM's vLLM-specific provider, or the `openai/` prefix because vLLM exposes an OpenAI-compatible API. Either works with the same endpoint URL. The name after the prefix must match your vLLM `--served-model-name`.
:::

## Cloud provider playbooks

For cloud models, prepare an API key, the model ID with its provider prefix, and network egress.

## Self-hosted vLLM patterns

Self-hosting gets you full data-residency control and unlimited request volume, but you own the inference server. Kindo recommends [vLLM](https://docs.vllm.ai/), and this section covers it.

### Pre-deployment checklist

- [ ] GPUs sized for your target context length (table below).
- [ ] NVIDIA drivers + `nvidia-container-runtime` installed; `nvidia-smi` shows your GPUs.
- [ ] Model weights pulled (HuggingFace token exported: `export HF_TOKEN=...`).
- [ ] Official model card read: context window, max output tokens, dtype, and any special flags.
- [ ] Correct `--tool-call-parser` identified for your model family.
- [ ] DNS/hostname planned; the endpoint will be reachable from the cluster.

### GPU sizing

:::caution[These numbers are estimates / ballpark figures only]
The VRAM figures below are rough starting points for capacity planning, not guarantees. Actual requirements vary with tokenizer vocab, batch size, concurrent request count, vLLM flags, and the specific model weights. **Always benchmark against your actual workload** before committing to hardware; treat the table as a guideline, not a spec.
:::

Context length is the primary VRAM driver via the KV cache. A 70B model at 4k context needs far less VRAM than the same model at 128k.

| Model size | Quantization | Short (4k) | Medium (32k) | Full (128k+) |
| ---------- | ------------ | ---------- | ------------ | ------------ |
| 7–8B       | FP16/BF16    | 1× 24GB    | 1× 24GB      | 1× 48GB      |
| 7–8B       | FP8          | 1× 24GB    | 1× 24GB      | 1× 24GB      |
| 13B        | FP16/BF16    | 1× 48GB    | 1× 80GB      | 1× 80GB      |
| 13B        | FP8          | 1× 24GB    | 1× 48GB      | 1× 80GB      |
| 30–34B     | FP16/BF16    | 1× 80GB    | 2× 80GB      | 2–4× 80GB    |
| 30–34B     | FP8          | 1× 48GB    | 1× 80GB      | 1–2× 80GB    |
| 70B        | FP16/BF16    | 2× 80GB    | 4× 80GB      | 4–8× 80GB    |
| 70B        | FP8          | 1× 80GB    | 2× 80GB      | 2–4× 80GB    |
| 70B        | AWQ/GPTQ     | 1× 80GB    | 2× 80GB      | 4× 80GB      |

:::tip
FP8 quantization roughly halves VRAM vs BF16/FP16 with minimal quality loss on most modern models. If you are GPU-constrained, try FP8 before AWQ/GPTQ. Estimates only; always test against your actual configuration.
:::

### Essential vLLM flags

:::caution[vLLM version depends on the model]
The vLLM version you need is not one-size-fits-all. Newer architectures (Qwen 3, DeepSeek V3, Nemotron, GPT OSS, etc.) frequently require a recent vLLM release, while some older or quantized formats are pinned to earlier versions. **Check the official model card (or the model's Hugging Face page) for the minimum vLLM version before pulling an image**, and plan to bump the vLLM container version when you change models. Running a model on an older vLLM than it supports usually surfaces as a load-time error or silently broken tool calls.
:::

```bash
vllm serve <model-id> \
  --served-model-name <name>          # must match the serving name you register
  --port 8000 \
  --max-model-len <context-length>    # the model's full context window
  --dtype bfloat16 \
  --tensor-parallel-size <num-gpus> \
  --tool-call-parser <parser> \       # required for agents
  --enable-auto-tool-choice \         # required alongside tool-call-parser
  --enable-prefix-caching \
  --enable-chunked-prefill
```

Check these flags if the model fails to start or call tools:

1. **`--max-model-len`**: set to the model's full context. If vLLM OOMs on startup, it will report the maximum your hardware can support; use that number, don't guess a lower one.
2. **`--tool-call-parser`**: without it, Kindo agents cannot call tools. Always pair with `--enable-auto-tool-choice`.

### Tool-call parser reference

| Model family            | `--tool-call-parser` | Notes                                                                      |
| ----------------------- | -------------------- | -------------------------------------------------------------------------- |
| NVIDIA Nemotron 3 Super | `qwen3_coder`        | Also set `--reasoning-parser nemotron_v3`. Requires `--trust-remote-code`. |
| Mistral / Mixtral       | `mistral`            |                                                                            |
| DeepSeek-V3 / R1        | `hermes`             | Verify against latest vLLM release.                                        |
| Qwen 3 / Qwen 3 Coder   | `qwen3_coder`        |                                                                            |
| DeepHat V3              | `qwen3_xml`          | Also set `--reasoning-parser qwen3`. See [DeepHat section](#deephat).      |
| GPT OSS                 | `openai`             | Also set `--reasoning-parser openai_gptoss`.                               |

:::caution[Parser support changes with vLLM releases]
Parser names and model coverage evolve. Cross-check the [vLLM tool calling docs](https://docs.vllm.ai/en/latest/features/tool_calling.html) for your vLLM version before deploying.
:::

### `--served-model-name` and the serving name

`--served-model-name` is the string vLLM uses for the `model` field in its OpenAI-compatible API. Kindo routes requests via LiteLLM, which resolves a registered serving name to its LiteLLM model ID (e.g. `openai/my-name` or `hosted_vllm/my-name`), then strips the prefix and sends `"model": "my-name"` to your inference server.

**The rule:** `--served-model-name` in vLLM must match the suffix of the LiteLLM model ID (after `openai/` or `hosted_vllm/`) **and** the serving name you register with Kindo.

```bash
vllm serve Qwen/Qwen3-Coder-30B-Instruct \
  --served-model-name qwen3-coder-30b \
  ...
```

Register that model with the serving name `qwen3-coder-30b`, the LiteLLM model ID `openai/qwen3-coder-30b`, and the endpoint URL `http://vllm-qwen.inference.svc.cluster.local:8000/v1`.

### Full example: NVIDIA Nemotron 3 Super on 4× H100

```bash
vllm serve nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-BF16 \
  --served-model-name nemotron \
  --port 8000 \
  --max-model-len 1000000 \
  --kv-cache-dtype fp8 \
  --dtype bfloat16 \
  --tensor-parallel-size 4 \
  --trust-remote-code \
  --tool-call-parser qwen3_coder \
  --enable-auto-tool-choice \
  --reasoning-parser nemotron_v3
```

## DeepHat

DeepHat V3 is Kindo's cybersecurity-focused model built for offensive reasoning, long-context analysis, and secure execution. Treat it like any other self-hosted vLLM model; the specifics below just call out its hardware and flag requirements.

### Hardware requirements

DeepHat V3 serves its **full 262,144-token context** on:

- **1× B200 GPU**, or
- **2× H100 GPUs**.

### Dependencies

- `vllm>=0.29.0` (brings all implicit dependencies).
- A HuggingFace access token provisioned by Kindo: `export HF_TOKEN=<token>`.

### Option A: Standalone vLLM

### Option B: Optional Helm chart

Skip this if you already have LLM serving infrastructure; run vLLM wherever you want and point Kindo at it. If you want a turnkey in-cluster deployment, Kindo ships a Helm chart.

`values-deephat.yaml` for 2× H100:

```yaml
model: DeepHat/DeepHat-V3-ext
servedModelName: deephat-v3
maxModelLen: 262144
dtype: bfloat16
tensorParallelSize: '2'
enableChunkedPrefill: 'true'
enablePrefixCaching: 'true'
enableAutoToolChoice: 'true'
toolCallParser: 'qwen3_xml'

resources:
  limits:
    nvidia.com/gpu: 2
  requests:
    nvidia.com/gpu: 2

hfToken: '<your_huggingface_token>'
vllmApiKey: '<your_api_key>'
```

For 1× B200, set `tensorParallelSize: "1"` and GPU resources to `1`.

Deploy:

```bash
helm install deephat-v3 . -f values-deephat.yaml
```

### Registering DeepHat

Once the endpoint is serving, register it from the superadmin dashboard's **Models** page:

- **Serving name:** `deephat-v3`
- **LiteLLM model ID:** `openai/deephat-v3` (or `hosted_vllm/deephat-v3`)
- **Display name:** DeepHat V3
- **Provider:** the OpenAI-compatible option
- **Provider display name:** the provider name your users should see, for example the team or service that hosts it
- **Credential:** endpoint URL `http://deephat-v3.inference.svc.cluster.local:8000/v1`, plus whatever you set as `vllmApiKey` above
- **Context window / max output tokens:** 262144 / 16384

:::caution
`servedModelName` / `--served-model-name` must match the serving name you register exactly. If they diverge, LiteLLM returns 404 on every request.
:::

## Verify: Is the endpoint reachable from the cluster?

**Always verify the endpoint from inside the cluster before registering the model.** Check DNS and firewall access from a pod in the cluster.

### Step 1: DNS from a pod

```bash
kubectl run dns-test --rm -it --restart=Never \
  --image=busybox:1.36 \
  -- nslookup <your-inference-host>
```

### Step 2: HTTP `/v1/models` from a pod

For a cluster-internal vLLM service:

```bash
kubectl run net-test --rm -it --restart=Never \
  --image=curlimages/curl:8.10.1 \
  -- curl -sS -m 5 http://<your-inference-host>:<port>/v1/models
```

For a cloud provider, use the provider's host with your key. For example, for Anthropic:

```bash
kubectl run net-test --rm -it --restart=Never \
  --image=curlimages/curl:8.10.1 \
  --env ANTHROPIC_API_KEY=sk-ant-... \
  -- sh -c 'curl -sS -m 10 https://api.anthropic.com/v1/models \
    -H "x-api-key: $ANTHROPIC_API_KEY" \
    -H "anthropic-version: 2023-06-01"'
```

Expected: a JSON response listing the model(s). If this fails, fix connectivity before proceeding; Kindo's own inference requests will fail the same way once the model is registered.

### Step 3 (self-hosted only): tool-call smoke test

```bash
kubectl run tool-test --rm -it --restart=Never \
  --image=curlimages/curl:8.10.1 \
  -- curl -sS -m 30 \
    -X POST http://<your-inference-host>:<port>/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
      "model": "<your-served-model-name>",
      "messages": [{"role": "user", "content": "What is the weather in SF?"}],
      "tools": [{
        "type": "function",
        "function": {
          "name": "get_weather",
          "description": "Get current weather for a location",
          "parameters": {
            "type": "object",
            "properties": {"location": {"type": "string"}},
            "required": ["location"]
          }
        }
      }],
      "tool_choice": "auto",
      "max_tokens": 256
    }'
```

Expected: the response contains a `tool_calls` array with `"name": "get_weather"` and `"location": "San Francisco"` (or similar). A plain text response means your `--tool-call-parser` is missing or wrong; agents will not work.

## Common pitfalls

| Pitfall                                         | Impact                                         | Prevention                                                            |
| ----------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------- |
| Context window too small                        | Conversations truncated, agents lose context   | Use the model's full advertised window                                |
| Missing `--tool-call-parser`                    | Agents cannot call tools                       | Always pair with `--enable-auto-tool-choice`                          |
| `--served-model-name` ≠ registered serving name | LiteLLM returns 404                            | Keep both strings identical                                           |
| DNS not reachable from cluster                  | Model registers but every request fails        | Verify with `kubectl run ... nslookup` first                          |
| Bedrock model not subscribed or not allowed     | 403 or `AccessDeniedException` from LiteLLM    | Subscribe to the model and allow it in IAM before registering it      |
| Azure missing the API version                   | LiteLLM rejects requests                       | Endpoint URL, API version, and API key are all required               |
| Gateway ignores `Authorization: Bearer`         | Model registers but every request gets 401/403 | Set `extra_headers` in **Additional litellm_params (JSON, optional)** |
| Skipped verification                            | Kindo blamed for inference bugs                | Complete endpoint verification before registering                     |

## Next

Once each endpoint passes the `kubectl run` checks, you're ready to install; model registration comes after the install completes.

---

## Install with kindo-cli

Source: https://docs.kindo.ai/deploy/install-with-kindo-cli/

Install the CLI, generate your configuration, and check your infrastructure before deploying Self-Managed Kindo (SMK) to your prepared Kubernetes cluster.

## 1. Install the CLI

The Kindo CLI is distributed as an OCI artifact at `oci://registry.kindo.ai/kindo-cli/kindo-cli`, pulled with `helm` using the same `registry.kindo.ai` credentials as the rest of the install. It contains the CLI wheel (`kindo_cli-*.whl`) and a `SHA256SUMS` file.

### Prerequisites on your install host

| Tool           | Required    | Version | Purpose                                                     |
| -------------- | ----------- | ------- | ----------------------------------------------------------- |
| `kubectl`      | Yes         | 1.32+   | Cluster access                                              |
| `helm`         | Yes         | v4+     | Chart deployment                                            |
| `helmfile`     | Yes         | v1.2+   | Release orchestration                                       |
| `yq`           | Yes         | v4+     | YAML processing                                             |
| `jq`           | Yes         | any     | Install scripts                                             |
| Python         | Yes         | 3.11+   | CLI runtime (installable via `uv`)                          |
| `uv`           | Recommended | latest  | Python + package manager in one binary                      |
| `psql`         | Optional    | any     | `kindo db` tunnels and prompts                              |
| Registry creds | Yes         | n/a     | `registry.kindo.ai` username + password (provided by Kindo) |

### Step 1: Install Python 3.11+ (skip if you already have it)

Check your current Python version:

```bash
python3 --version
```

If it reports 3.11 or higher, skip to Step 2. Otherwise install `uv`, which will also install Python 3.11 for you.

```bash
curl -LsSf https://astral.sh/uv/install.sh | sh
export PATH="$HOME/.local/bin:$PATH"
uv --version
```

### Step 2: Pull the CLI artifact

Log in to the Kindo registry, then pull and unpack the artifact at your target release version:

```bash
helm registry login registry.kindo.ai --username <registry-username>
helm pull oci://registry.kindo.ai/kindo-cli/kindo-cli --version <release> --untar
```

Verify the wheel checksums before installing:

```bash
(cd kindo-cli && sha256sum -c SHA256SUMS)
```

For air-gapped installs, pull the `.tgz` on a connected machine and transfer it to the install host, or pull from a registry that mirrors `registry.kindo.ai`.

### Step 3: Install the CLI wheel

**Recommended: via `uv` (isolates the CLI in its own environment):**

```bash
uv tool install --force ./kindo-cli/kindo_cli-*.whl
```

**Alternative: via `pip` (if you already have Python 3.11+):**

```bash
python3.11 -m pip install ./kindo-cli/kindo_cli-*.whl
```

The glob matches the version in the wheel's filename.

To upgrade, pull the target release and re-run the same install command.

### Step 4: Verify the installation

```bash
kindo --version
kindo --help
```

If the help output prints, the CLI is installed and on your `PATH`. If `kindo` is not found, ensure `$HOME/.local/bin` is on `PATH` (uv installs CLIs there by default).

## 2. Generate config with `kindo config init`

The config wizard produces the two files every subsequent command reads:

- **`install-contract.yaml`**: _what_ to deploy (version, base domain, registry credentials, superadmin email (`operatorEmail`), applications, peripheries, secrets-store backend, SMTP, optional integrations).
- **`environment-bindings.yaml`**: _where_ your infrastructure lives (PostgreSQL admin connection strings, an optional dedicated Hatchet instance, Redis, RabbitMQ, S3-compatible storage).

Run the wizard in the directory where you want the config files written:

```bash
kindo config init
```

### Wizard sections

Draft state is saved to `.kindo-config-draft.json` as you go, so you can quit with Ctrl-C and resume later.

:::note
Edit `install-contract.yaml` and `environment-bindings.yaml` in any editor, then run `kindo config validate`.
:::

### Draft-resume behavior

If you quit partway through, re-running `kindo config init` detects the draft and offers to continue where you left off:

```text
Found incomplete wizard draft (completed through section 4/10)
  Continue where you left off? [Y/n]:
```

If the final `install-contract.yaml` and `environment-bindings.yaml` files already exist, the wizard offers to load them as defaults and edit in place.

### Output

On success the wizard prints:

```text
✓ Configuration files created

  install-contract.yaml
  environment-bindings.yaml
```

:::tip
Review both files and correct any typos before moving on.
:::

<details>
<summary>Full example <code>install-contract.yaml</code></summary>

```yaml
apiVersion: kindo.ai/v1
metadata:
  schemaVersion: '2'
baseDomain: kindo.example.com
appVersion: <release>
storageClass: <storage-class>
registry:
  username: <registry-username>
  password: <registry-password>
applications:
  api: true
  next: true
  superadmin: true
  litellm: true
  credits: true
  cerbos: true
  prisma-migrations: true
  hatchet: true
  nango: true
  task-worker-ts: true
  mcp-unified: true
  mcp-platform: true
  sandbox: true
peripheries:
  qdrant: true
  presidio: true
  speaches: true
  otel-collector: true
operatorEmail: operator@example.com
secretsStore:
  backend: kubernetes
smtp:
  host: smtp.example.com
  port: '587'
  user: <smtp-user>
  password: <smtp-password>
  fromEmail: noreply@kindo.example.com
logLevel: info
ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/force-ssl-redirect: 'true'
    nginx.ingress.kubernetes.io/proxy-body-size: '0'
  tls:
    mode: cert-manager
    clusterIssuer: letsencrypt-prod
```

</details>

The `ingress:` block is optional. With it omitted, route the hosts from `kindo ingress manifest` through your own controller. With `enabled: true`, the CLI renders one Ingress per host through `className`, applies `annotations` to every Ingress, and handles TLS per `tls.mode`: `cert-manager`, `secret`, `acm` (AWS Certificate Manager), or `none`. Hosts follow `endpoints` and `baseDomain`.

The example uses ingress-nginx with cert-manager. Each host gets `cert-manager.io/cluster-issuer: letsencrypt-prod` and a `spec.tls` entry with secret `<release>-<instance>-tls` (for example `api-main-tls`). For streaming chat responses on nginx, set the `api` release's buffering and timeouts:

```bash
kindo config helm-override set api \
  'ingress.annotations.nginx\.ingress\.kubernetes\.io/proxy-buffering=off' \
  'ingress.annotations.nginx\.ingress\.kubernetes\.io/proxy-read-timeout=3600' \
  'ingress.annotations.nginx\.ingress\.kubernetes\.io/proxy-send-timeout=3600'
```

For other ingress controllers, use the following examples:

<details>
<summary>AWS Load Balancer Controller with an ACM certificate</summary>

```yaml
ingress:
  enabled: true
  className: alb
  annotations:
    alb.ingress.kubernetes.io/group.name: kindo-shared
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'
  tls:
    mode: acm
    acmCertificateArn: arn:aws:acm:us-west-2:123456789012:certificate/<certificate-id>
```

On `alb`, set load-balancer-level keys (scheme, certificate, listeners, security groups) only in the contract's `ingress.annotations`; a per-release override of them is rejected at install and upgrade.

</details>

<details>
<summary>Kong Ingress Controller with a pre-provisioned wildcard certificate</summary>

```yaml
ingress:
  enabled: true
  className: kong
  annotations:
    konghq.com/protocols: https
    konghq.com/https-redirect-status-code: '301'
    konghq.com/strip-path: 'false'
  tls:
    mode: secret
    secretName: kindo-wildcard-tls
```

Create `kindo-wildcard-tls` in each publishing namespace. Each host gets a `spec.tls` entry referencing that Secret. For SSE on `api`, raise Kong's route timeouts (milliseconds):

```bash
kindo config helm-override set api \
  'ingress.annotations.konghq\.com/read-timeout=3600000' \
  'ingress.annotations.konghq\.com/write-timeout=3600000'
```

</details>

`mcp-platform` (the agent tools adapter) is installed by default, and new installs turn on Platform tools and MCP account routing through the `PLATFORM_MCP` and `MCP_ACCOUNT_ROUTING` feature flags. MCP account routing lets users select more than one integration connection for a tool server. To opt out of the adapter, set `applications.mcp-platform: false` and turn off `PLATFORM_MCP` in Unleash at `https://unleash.<domain>`.

The superadmin dashboard is installed by default and served at `superadmin.<domain>`. Publish its DNS record with the others ([DNS subdomains](/deploy/provision-infrastructure/#dns-subdomains)).

<details>
<summary>Full example <code>environment-bindings.yaml</code></summary>

```yaml
apiVersion: kindo.ai/v1
postgres:
  admin:
    connectionString: postgresql://<admin-user>:<admin-password>@postgres.example.com:5432/postgres?sslmode=require
  adminAuxiliary:
    connectionString: postgresql://<admin-user>:<admin-password>@postgres-auxiliary.example.com:5432/postgres?sslmode=require
  adminHatchet:
    connectionString: postgresql://<admin-user>:<admin-password>@postgres-hatchet.example.com:5432/postgres?sslmode=require
redis:
  connectionString: redis://redis.example.com:6379
rabbitmq:
  connectionString: amqps://<rabbitmq-user>:<rabbitmq-password>@rabbitmq.example.com
storage:
  bucketName: kindo-uploads
  region: <region>
  accessKey: <storage-access-key>
  secretKey: <storage-secret-key>
  endpointUrl: https://storage.example.com
  endpointUrlPublic: https://downloads.example.com
```

</details>

## 3. Preflight your infrastructure

Check that your cluster can reach the dependencies listed in `environment-bindings.yaml`:

```bash
kindo config validate --preflight --test-email
```

`kindo config validate` checks the configuration schema. With `--preflight`, it also:

The checks run inside your cluster, in this order:

- **PostgreSQL**: main and auxiliary admin endpoints reachable, credentials valid.
- **Hatchet database**: the Hatchet instance and its recommended settings; see [PostgreSQL settings for Hatchet](/deploy/provision-infrastructure/#postgresql-settings-for-hatchet).
- **Redis**: reachable on the provided connection string.
- **RabbitMQ**: reachable (AMQP or AMQPS).
- **S3-compatible storage**: bucket accessible with the provided credentials or workload identity. Warns when the storage endpoint resolves only inside the cluster and no public endpoint is set, because user download links would then be unreachable; see [S3-compatible object storage](/deploy/provision-infrastructure/#s3-compatible-object-storage).
- **SMTP**: handshake, plus authentication when `smtp.user` and `smtp.password` are set. Warns when they're unset, so you can confirm the relay accepts the cluster's addresses.
- **SMTP test email**: one message from `smtp.fromEmail` to `operatorEmail`, so a relay that accepts the connection but rejects the message fails preflight instead of failing sign-in codes later. `kindo config validate` sends it only with `--test-email`, which is why the command above includes it; `kindo upgrade --apply` sends it unless you pass `--no-test-email`. If the send is rejected, make the relay deliver to `operatorEmail`, because sign-in codes go there; use `--no-test-email` only as an escape hatch, for example when delivery is known to work and only the test send is unwanted. `--test-email` fails when `operatorEmail` is empty.
- **DNS**: `baseDomain` and its derived subdomains resolve.
- **Nodes**: enough ready nodes.
- **StorageClass**: the configured `storageClass` resolves in the cluster.
- **cert-manager**: present when TLS is expected.
- **Ingress controller**: at least one IngressClass is available.

:::caution[Fix preflight failures]
A failing preflight is much cheaper to debug than a half-applied install. Re-run `kindo config validate --preflight --test-email` after every fix until every check passes before moving on.
:::

## 4. Preview with `kindo install --plan`

`--plan` provides a read-only preview of the install:

```bash
kindo install --plan
```

It prints:

- **Install settings**: domain, version, Postgres host (password masked), storage bucket.
- **Prerequisites**: a green tick per required tool and a dot per optional tool.
- **Cluster reachability**: confirms your kubeconfig can talk to the cluster.
- **Steps**: the ordered list of install steps with their one-line descriptions.

The plan also flags a missing `operatorEmail`.

## 5. Apply with `kindo install --apply`

Once the plan looks right, run the install:

```bash
kindo install --apply
```

`--apply` stops before changing anything if `operatorEmail` is missing from `install-contract.yaml`.

The installer runs these steps in order:

| #   | Step                   | Purpose                                                                                                                                                                                                                                                       |
| --- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1   | `generate-secrets`     | Generate secrets and store them in the cluster.                                                                                                                                                                                                               |
| 2   | `merge-bindings`       | Merge infrastructure bindings into the secrets config.                                                                                                                                                                                                        |
| 3   | `setup-registry`       | Configure image pull secrets in all namespaces.                                                                                                                                                                                                               |
| 4   | `external-secrets`     | Install the External Secrets Operator (operator, CRDs, webhook). The installer uses an existing ESO if it serves `external-secrets.io/v1` (ESO 0.17 or later). An older ESO fails the step with upgrade guidance.                                             |
| 5   | `db-bootstrap`         | Create databases and service users.                                                                                                                                                                                                                           |
| 6   | `peripheries`          | Deploy Unleash (+ Edge), Qdrant, Presidio, Speaches, Hatchet, the OTel Collector, ClickHouse and HyperDX. See [Observability](/deploy/observability/).                                                                                                        |
| 7   | `hatchet-token`        | Store the Hatchet API token in the secrets config.                                                                                                                                                                                                            |
| 8   | `migrations`           | Run database schema migrations.                                                                                                                                                                                                                               |
| 9   | `applications`         | Deploy the application services enabled in `install-contract.yaml`. The wizard enables api, next, superadmin (the superadmin dashboard), litellm, credits, cerbos, prisma-migrations, hatchet, nango, task-worker-ts, mcp-unified, mcp-platform, and sandbox. |
| 10  | `superadmin-bootstrap` | Create the superadmin account for `operatorEmail` and print its key once. Re-runs print `already bootstrapped` and issue no key. The step fails if no superadmin exists afterwards.                                                                           |
| 11  | `post-install`         | Nango bootstrap and feature flags.                                                                                                                                                                                                                            |
| 12  | `integrations`         | Reconcile enabled integrations. Skips when none are enabled. A failure is recorded and reported, and the install finishes with a warning that integrations failed. Re-run with `kindo install --step integrations`.                                           |

:::caution[Store your superadmin key]
The `superadmin-bootstrap` step prints your key once in a highlighted panel. Store it in your secret manager immediately. If you lose it, sign in to the superadmin dashboard and create a new one under **Keys** > **New key**.
:::

During execution the CLI streams a live table of Helm release states (`◐` pending, `✓` deployed, `✗` failed) plus the notable lines from scripts (`[STEP]`, `[INFO]`, `[WARN]`). Add `--verbose` to see the raw `helmfile` output.

:::note
If a step fails, the CLI prints the error output and writes the failure to the state ConfigMap:

```text
✗ failed (27s)
    Error: release litellm failed: ...
```

Run `kindo install --resume` to pick up from the failed step: the CLI re-runs whichever step is marked `failed` (or `running`, if interrupted) in `kindo-install-state` and then continues through the rest of the sequence.

If the final `integrations` step fails, the install records `integrations: failed` in `kindo-install-state` and finishes with a warning that integrations failed. Fix the cause, then re-run that step:

```bash
kindo install --step integrations
```

:::

## 6. Resume or replay steps

After a failure (or an intentional Ctrl-C), resume with:

```bash
kindo install --resume
```

`--resume` stops before changing anything if `operatorEmail` is missing. It skips steps marked `completed` in `kindo-install-state` and picks up at the first unfinished step. Existing generated secrets are preserved.

If the contract has changed since the last run, the CLI warns you:

```text
Warning: Config changed since last run. Verify changes are intentional.
```

The warning means you changed the config files between runs. Check that the change was intended. The install continues.

Re-run a single step by name:

```bash
kindo install --step applications
kindo install --step post-install
kindo install --step hatchet-token
```

`--step` runs the named step independently and updates its state in `kindo-install-state` on completion. Use it to retry a failed step.

:::caution[Re-running post-install resets feature flags]
`post-install` overwrites every Unleash flag with the shipped default. Change individual flags in Unleash instead. If you re-run the step, reapply your flag changes afterward, such as turning off `PLATFORM_MCP` or `MCP_ACCOUNT_ROUTING`.
:::

Use `--release <name>` to narrow a group step to one release:

```bash
kindo install --step applications --release api
```

`kindo install --step superadmin-bootstrap` re-runs the bootstrap. If a superadmin already exists, it issues no key. It exits non-zero if no superadmin exists afterwards.

`kindo install --step sync-flags` adds feature flags new in the target version without changing existing ones.

## 7. State introspection

Install state lives in the cluster. Anyone with cluster access and the CLI can observe or resume an install.

### `kindo status`

```bash
kindo status
```

Prints Version, Started, Contract hash, and a per-step table:

```text
Kindo Install State
  Version:       2026.09.0
  Started:       2026-09-25T14:02:17
  Contract hash: 7c0a3e...

Step                   Status            Completed             Error
generate-secrets       ✓ completed       2026-09-25T14:02:35
merge-bindings         ✓ completed       2026-09-25T14:02:41
setup-registry         ✓ completed       2026-09-25T14:02:48
external-secrets       ✓ completed       2026-09-25T14:04:12
db-bootstrap           ✓ completed       2026-09-25T14:05:02
peripheries            → running
hatchet-token          ○ pending
migrations             ○ pending
applications           ○ pending
superadmin-bootstrap   ○ pending
post-install           ○ pending
integrations           ○ pending
```

Below the step table, the `Superadmin:` line reports whether the install has a superadmin, for example `✓ bootstrapped`. A live release table follows with each release's chart version, image tags, and health. Use `kindo status --no-live` to skip the live checks. See [Operate](/deploy/operate/) for interpreting status and diagnosing failures.

### `kindo-install-state` ConfigMap

State is stored in the `kindo-install-state` ConfigMap in the `kindo-system` namespace:

```bash
kubectl -n kindo-system get cm kindo-install-state -o yaml
```

Keys:

- `meta.json`: `{ version, contract_hash, started_at }`
- `step.<name>`: `{ status, started_at, completed_at, error }` for each step, where `status ∈ { pending, running, completed, failed, skipped }`.

The ConfigMap is created on first run and labeled `app.kubernetes.io/managed-by=kindo-cli`. The CLI manages lifecycle; do not edit it by hand except in break-glass scenarios.

### `kindo-secrets-config` Secret

All cluster-resident secrets (generated passwords, API keys, encryption keys, merged infrastructure connection strings, Hatchet client token) live in the `kindo-secrets-config` Secret in `kindo-system`:

```bash
kubectl -n kindo-system get secret kindo-secrets-config -o jsonpath='{.data.secrets\.yaml}' | base64 -d
```

Restrict who can read this Secret.

## Managing integrations

To enable, disable, and deploy integrations after the install, see [`kindo integrations`](/deploy/operate/#kindo-integrations).

## Next

---

## Configure & Validate

Source: https://docs.kindo.ai/deploy/configure-and-validate/

After `kindo install --apply` finishes, take the deployment from running pods to users signing in: publish DNS, terminate TLS, sign in to the superadmin dashboard, create the first organization and its SSO, and run a smoke test.

## 1. Publish DNS records

:::caution[DNS propagation delay]
Freshly-created records can take 1 to 5 minutes to propagate depending on TTL. If `dig` returns nothing, wait a minute and retry before assuming the record is wrong.
:::

### Routing requirements that can't be left at defaults

When the contract's `ingress:` block is enabled, the CLI creates the path rules below. Apply the streaming settings and provider requirements for your ingress controller.

- **App host routing on `app.<domain>`**: the CLI sends `/auth`, `/trpc`, and `/express` to `api` ahead of `/` to `next`. These paths match segments: `/auth` matches `/auth/callback`, but not `/authentication`. `/api/*` stays on `next` for Next.js routes. See [App host routes](/deploy/ingress/#app-host-routes).
- **Server-Sent Events on `/express/chat`**: the API streams chat responses as SSE. Your ingress must **disable response buffering**, allow **read/send timeouts ≥ 300s**, allow **unlimited response body size**, and **preserve response content**. In NGINX that's `proxy_buffering off` plus generous `proxy_read_timeout` / `proxy_send_timeout`. In Traefik set `respondingTimeouts`; in Envoy set `stream_idle_timeout`. Default buffering and 60s timeouts truncate chat responses.
- **Hatchet path-based routing on `hatchet.<domain>`**: route `/api/*` to `hatchet-api` **with higher priority** than `/*`, which routes to the admin UI (`hatchet-frontend`).
- **AWS Load Balancer Controller with a non-VPC CNI**: see [Provider notes](/deploy/provision-infrastructure/#provider-notes).
- **Superadmin dashboard routing on `superadmin.<domain>`**: route `/auth` and `/superadmin` to `api` **ahead of** `/` to `superadmin`. Match `/auth` and `/superadmin` as path segments. With an AWS ALB IngressGroup, give the `api` rules the lower `group.order`.

## 2. Terminate TLS at the ingress

If the contract's `ingress:` block is enabled, the CLI renders every Ingress object and TLS follows `ingress.tls.mode`: `acm`, `cert-manager`, `secret`, or `none`. Follow this section when you route the hosts yourself (`kindo ingress manifest` lists them).

Choose one of the following options.

### Option A: cert-manager (recommended)

:::caution[Check certificate readiness]
If certificates stay in `Issuing` state longer than a minute, check that your `ClusterIssuer` is `Ready` and that the ACME HTTP-01 solver can reach the cluster over port 80. `kubectl describe challenge -A` usually surfaces the root cause.
:::

### Option B: manual certs

## 3. Sign in and set up the first organization

## 4. Limit the sign-in methods shown

The app's `/login` offers SAML SSO, an emailed one-time code, and, once configured, Google. To offer SAML only, or SAML plus one of the others, hide the other methods. The toggles control button visibility; the API routes remain available.

The toggles are env vars on the `next` release. A method is hidden only when the value is `false` (case-insensitive, surrounding whitespace ignored); unset means shown. Google is set to `false` by default. To offer it, set `GOOGLE_OAUTH_CLIENT_ID` and `GOOGLE_OAUTH_CLIENT_SECRET` on the `api` release, then set `NEXT_PUBLIC_ENABLE_GOOGLE_LOGIN=true`.

```bash
kindo config override set next NEXT_PUBLIC_ENABLE_GOOGLE_LOGIN=false NEXT_PUBLIC_ENABLE_EMAIL_OTP_LOGIN=false
kindo config override apply next
```

On an install that delivers secrets from an external store, `kindo config override` refuses to run. Set the same keys as chart values:

```bash
kindo config helm-override set next envData.NEXT_PUBLIC_ENABLE_GOOGLE_LOGIN=false envData.NEXT_PUBLIC_ENABLE_EMAIL_OTP_LOGIN=false
kindo config helm-override apply next
```

To bring a method back, remove the override with `kindo config override unset next 

## Where to next

---

## Observability Guide

Source: https://docs.kindo.ai/deploy/observability/

Use HyperDX to search logs, traces, and metrics from your install. Kindo ships [ClickStack](https://clickhouse.com/clickstack) in the cluster: the OpenTelemetry Collector collects telemetry, ClickHouse stores it, and HyperDX provides search and dashboards.

## Architecture

```
+-----------------------------------------------------------+
|                       Kindo Services                      |
+-----------+-----------+-----------+-----------+-----------+
|    API    |    Task   |  Credits  |  LiteLLM  |  Next.js  |
|           |   Worker  |           |           |           |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
      |           |           |           |           |
      +-----------+-----------+-----------+-----------+
                              | OTLP (traces, metrics, logs)
    +------------+            |       +---------------+
    |   Agent    |            |       | Logs DaemonSet|
    | Prometheus |            |       |  pod stdout   |
    +-----+------+            |       +-------+-------+
          | OTLP              |               | OTLP
          +-------------------+---------------+
                              |
                              v
                      +-------+-------+
                      |    Gateway    |
                      | OTel Collector|
                      +-------+-------+
                              |
                              v
                      +-------+-------+
                      |  ClickHouse   |
                      +-------+-------+
                              ^
                              | queries
                      +-------+-------+
                      | HyperDX (UI)  |
                      +---------------+
```

To check collector health, inspect the `otel-collector` release in the `kindo-monitoring` namespace. Its workloads are:

- **Gateway**: receives telemetry and exports it to ClickHouse.
- **Agent**: collects Prometheus metrics and forwards them to the gateway.
- **Logs DaemonSet**: collects pod stdout from the namespaces configured under [Log collection](#log-collection).

See [Choose a size](/deploy/provision-infrastructure/#1-choose-a-size) for storage and compute requirements.

## Application telemetry

Kindo services send traces, metrics, and logs to the gateway automatically.

For custom applications in the cluster, configure `OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector-gateway.kindo-monitoring:4317` and `OTEL_EXPORTER_OTLP_PROTOCOL=grpc` to send telemetry to ClickStack.

## Log collection

Kindo application logs arrive through OTLP. The logs DaemonSet also collects pod stdout from the `hatchet`, `nango`, and `ingress-nginx` namespaces by default, excluding the `linkerd-proxy` sidecar container. Hatchet logs require this collection even when Hatchet traces and metrics are visible.

Use [Helm overrides](/deploy/operate/#kindo-config-helm-override) to enable collection or add namespaces:

1. Enable the logs DaemonSet if it is disabled:

   ```bash
   kindo config helm-override set otel-collector logs.enabled=true
   kindo config helm-override apply otel-collector
   ```

2. Add a namespace for another component that logs to stdout. Helm replaces lists wholesale, so include the defaults along with your namespace:

   ```bash
   kindo config helm-override set otel-collector \
     'logs.namespaces[0]=hatchet' 'logs.namespaces[1]=nango' \
     'logs.namespaces[2]=ingress-nginx' 'logs.namespaces[3]=<your-namespace>'
   kindo config helm-override apply otel-collector
   ```

3. Check HyperDX for logs from that namespace.

Collect stdout only for components that do not already send logs over OTLP, to avoid storing duplicate records. If a component's logs are missing, check `logs.enabled` and `logs.namespaces` even when its traces or metrics appear.

## Accessing HyperDX

1. Open `https://hyperdx.<your-base-domain>`.
2. Read the initial admin credentials from the secrets config:

   ```bash
   kindo config edit
   ```

   The email is `clickstack.hyperdxAdminEmail`, which defaults to `hyperdx@<base domain>`. The password is `clickstack.hyperdxAdminPassword`. Quit the editor without saving.

3. Sign in. Change the password in the HyperDX UI when needed.

## Default dashboards

Find the installed dashboards under **Dashboards** in HyperDX, tagged `kindo-defaults`:

- **Agent Monitoring: Overview**: run outcomes, success rate, and execution duration across agents.
- **Agent Monitoring: Agent Run Details**: one agent's runs, and for a selected run, its steps and errors.
- **Issue Inspector**: why a chat or agent run went wrong. Paste a conversation, agent run, agent, organization, or user ID into its filters to see turn outcomes, each failed turn with what failed (the AI model or which tool) and its error, and integrations that couldn't connect.

Start with **Agent Monitoring: Overview** and select an agent. On **Agent Run Details**, select a run to load it, then use the **Run** tab for its steps and the **Errors** tab for its errors.

Create your own dashboard with a new name for custom views. Default dashboards are overwritten on deploy and upgrade; dashboards outside the default set persist.

## Signals and retention

Logs, traces, and metrics are enabled by default and stored in ClickHouse. Retention defaults to `INTERVAL 7 DAY` in the `clickhouse` release's `schema.tablesTtl` setting.

To change retention:

1. Check disk capacity before increasing the retention period.
2. Set and apply the retention interval, for example:

   ```bash
   kindo config helm-override set clickhouse 'schema.tablesTtl=INTERVAL 14 DAY'
   kindo config helm-override apply clickhouse
   ```

ClickHouse stores logs, traces, and metrics on the same persistent volumes. Watch disk usage on the ClickHouse PVCs. When free space drops to the chart's insert floor (10% of the volume), ClickHouse rejects new telemetry until retention frees space. Telemetry is dropped in the meantime. Lower `schema.tablesTtl` with the commands above or [expand the volumes](/deploy/scaling-and-tuning/#observability-storage). Volumes can grow but cannot shrink. See [Choose a size](/deploy/provision-infrastructure/#1-choose-a-size) for sizing.

During a fresh install, collector pods wait in init until the ClickHouse schema migration finishes. If they stay there, check the migration Job and ClickHouse pod health.

## Troubleshooting

| Symptom                                                  | Cause                                                                                                        | Solution                                                                                                                                                                                         |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| No traces/metrics in HyperDX                             | Application telemetry is disabled or missing                                                                 | Confirm the collector is enabled and the service has its OTLP endpoint                                                                                                                           |
| No logs from an OTLP service                             | Gateway is not ingesting                                                                                     | Check that gateway pods are Running and have completed initialization                                                                                                                            |
| No logs from Hatchet, Nango, or another tailed component | Logs DaemonSet is disabled or its namespace is missing                                                       | Set `logs.enabled` and `logs.namespaces` with `kindo config helm-override set otel-collector`, then run `kindo config helm-override apply otel-collector`; see [Log collection](#log-collection) |
| Collector pods stuck in init                             | ClickHouse schema migration has not finished                                                                 | Check the migration Job and ClickHouse pod health                                                                                                                                                |
| Custom app telemetry missing                             | Wrong endpoint or protocol                                                                                   | Use the gateway OTLP endpoint above with `grpc`                                                                                                                                                  |
| ClickHouse disk filling                                  | Retained telemetry exceeds disk headroom                                                                     | Lower `schema.tablesTtl` with `kindo config helm-override set clickhouse`, then run `kindo config helm-override apply clickhouse`, or expand the persistent volumes                              |
| Long log fields appear truncated                         | Large string fields in application logs are truncated before export, with a marker showing the original size | Expected; no action needed.                                                                                                                                                                      |

---

## Customize Branding (Whitelabel)

Source: https://docs.kindo.ai/deploy/customize-branding/

Set your own app name, logo, favicon, footer disclaimer, and policy URLs for Self-Managed Kindo. Use environment-variable defaults for branding across the install, and the `CUSTOM_WHITELABEL` feature flag for per-organization changes.

## How branding resolves

Branding uses the first available value in this order:

1. The `CUSTOM_WHITELABEL` variant payload matching the organization's `orgId`.
2. The environment-variable default for that field.
3. The built-in Kindo default for an optional field without an environment-variable value.

Omit a payload field to inherit its environment-variable default. `appName` also changes the API documentation titles; the other fields affect only the web app.

:::note
`CUSTOM_WHITELABEL` is off by default. Leave it off to use environment-variable defaults globally. Enable it for per-organization overrides.
:::

## Environment-variable defaults

The charts ship Kindo defaults for every field, so no branding settings are required to install. Set the values below to rebrand. Services use these defaults when `CUSTOM_WHITELABEL` is off or a payload omits a field.

| Environment variable                                | Service                 | Set to rebrand | Purpose                                                    |
| --------------------------------------------------- | ----------------------- | -------------- | ---------------------------------------------------------- |
| `NEXT_PUBLIC_DEFAULT_APP_NAME`                      | `next`                  | Yes            | Product name in the web app                                |
| `NEXT_PUBLIC_DEFAULT_LOGO_URL`                      | `next`                  | Yes            | HTTPS URL to the logo image                                |
| `NEXT_PUBLIC_DEFAULT_FAVICON_URL`                   | `next`                  | Yes            | HTTPS URL to the favicon                                   |
| `NEXT_PUBLIC_DEFAULT_PRIVACY_URL`                   | `next`                  | Yes            | HTTPS URL to the privacy policy                            |
| `NEXT_PUBLIC_DEFAULT_TERMS_OF_USE_URL`              | `next`                  | Yes            | HTTPS URL to the terms of use                              |
| `NEXT_PUBLIC_DEFAULT_TERMS_OF_SERVICE_URL`          | `next`                  | Yes            | HTTPS URL to the terms of service                          |
| `NEXT_PUBLIC_DEFAULT_MARKETING_WEBSITE_CONTACT_URL` | `next`                  | Yes            | HTTPS URL for the "Contact us" link                        |
| `NEXT_PUBLIC_DEFAULT_PUBLIC_DOCS_URL`               | `next`                  | No             | HTTPS URL to your Kindo Docs site                          |
| `NEXT_PUBLIC_DEFAULT_DISCLAIMER`                    | `next`                  | No             | Footer disclaimer text                                     |
| `NEXT_PUBLIC_DEFAULT_DISCLAIMER_POLICY_URL`         | `next`                  | No             | HTTPS URL linked from the disclaimer                       |
| `DEFAULT_APP_NAME`                                  | `api`, `task-worker-ts` | Yes            | Product name in API documentation and server-rendered text |
| `DEFAULT_PUBLIC_DOCS_URL`                           | `task-worker-ts`        | No             | Base URL for Kindo Docs search results                     |

Configured URL fields must use HTTPS. `DEFAULT_PUBLIC_DOCS_URL` is empty by default on Self-Managed Kindo installs, so documentation search stays off until you set it.

To set global defaults:

1. Set and apply the web app's branding:

   ```bash
   kindo config override set next NEXT_PUBLIC_DEFAULT_APP_NAME="Acme AI" NEXT_PUBLIC_DEFAULT_LOGO_URL=https://cdn.acme.example.com/logo.svg
   kindo config override apply next
   ```

2. Set and apply the corresponding application name on the backend services:

   ```bash
   kindo config override set api DEFAULT_APP_NAME="Acme AI"
   kindo config override apply api
   kindo config override set task-worker-ts DEFAULT_APP_NAME="Acme AI"
   kindo config override apply task-worker-ts
   ```

3. Set the remaining values from the table with the same commands for their named services. See [Service overrides](/deploy/operate/#kindo-config-override).

With an external secrets store, `kindo config override` refuses to run. Set the same keys as chart values and apply them:

```bash
kindo config helm-override set next 'envData.NEXT_PUBLIC_DEFAULT_APP_NAME=Acme AI' envData.NEXT_PUBLIC_DEFAULT_LOGO_URL=https://cdn.acme.example.com/logo.svg
kindo config helm-override apply next
kindo config helm-override set api 'envData.DEFAULT_APP_NAME=Acme AI'
kindo config helm-override apply api
kindo config helm-override set task-worker-ts 'envData.DEFAULT_APP_NAME=Acme AI'
kindo config helm-override apply task-worker-ts
```

Kindo Docs search requires the `KINDO_DOCS_SEARCH` flag, a `DEFAULT_PUBLIC_DOCS_URL` pointing to a Kindo Docs site from the same documentation release as your install, and a disabled `CUSTOM_WHITELABEL` variant for the requesting organization. An enabled variant disables documentation search, including when `publicDocsUrl` is set or the payload is invalid.

## Variant payload schema

Use a JSON payload to override fields for an organization. All fields are optional; omitted fields inherit the environment-variable defaults.

| Field                        | Type      | Purpose                                                                    |
| ---------------------------- | --------- | -------------------------------------------------------------------------- |
| `appName`                    | string    | Product name in the web app, API documentation, and server-rendered titles |
| `logoUrl`                    | HTTPS URL | Top navigation and login logo                                              |
| `faviconUrl`                 | HTTPS URL | Browser tab favicon                                                        |
| `disclaimer`                 | string    | Footer disclaimer text                                                     |
| `dashboardDisclaimer`        | string    | Dashboard disclaimer; falls back to `disclaimer` when omitted              |
| `disclaimerPolicyUrl`        | HTTPS URL | Link from the disclaimer                                                   |
| `privacyUrl`                 | HTTPS URL | Privacy policy link                                                        |
| `termsOfUseUrl`              | HTTPS URL | Terms of use link                                                          |
| `termsOfServiceUrl`          | HTTPS URL | Terms of service link                                                      |
| `marketingWebsiteContactUrl` | HTTPS URL | "Contact us" link                                                          |
| `publicDocsUrl`              | HTTPS URL | Public docs link                                                           |

An invalid payload, such as malformed JSON, a non-HTTPS URL, or a wrong type, produces a warning in the logs. Branding falls back to the environment-variable defaults for the entire payload.

### Example payload

```json
{
  "appName": "Acme AI",
  "logoUrl": "https://cdn.acme.example.com/branding/logo.svg",
  "faviconUrl": "https://cdn.acme.example.com/branding/favicon.png",
  "disclaimer": "Acme AI is for internal use only. Do not paste customer PII.",
  "disclaimerPolicyUrl": "https://acme.example.com/legal/ai-policy",
  "privacyUrl": "https://acme.example.com/legal/privacy",
  "termsOfUseUrl": "https://acme.example.com/legal/terms",
  "termsOfServiceUrl": "https://acme.example.com/legal/tos",
  "marketingWebsiteContactUrl": "https://acme.example.com/contact",
  "publicDocsUrl": "https://docs.acme.example.com"
}
```

## Configure branding for an org

## Global branding without per-org overrides

For the same branding across all organizations, leave `CUSTOM_WHITELABEL` off and set `NEXT_PUBLIC_DEFAULT_*` and `DEFAULT_APP_NAME` using the [override commands above](#environment-variable-defaults). Set `DEFAULT_PUBLIC_DOCS_URL` on `task-worker-ts` when documentation search results should link to your Kindo Docs site from the same documentation release as your install.

## Troubleshooting

| Symptom                                                  | Likely cause                                                     | Fix                                                                                                   |
| -------------------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Branding shows Kindo defaults even with the flag enabled | Branding defaults are unset and the payload does not supply them | Set and apply the values using the [override commands above](#environment-variable-defaults)          |
| Logo or favicon does not load                            | Asset URL uses `http://`                                         | Re-host the asset over HTTPS                                                                          |
| Variant payload is ignored                               | Invalid JSON, URL, or field type                                 | Check `api` and `next` pod logs for `Invalid CUSTOM_WHITELABEL payload` or `Failed to parse` warnings |
| Wrong organization sees the branding                     | Variant strategy is missing the `orgId` constraint               | Add a **Gradual rollout** strategy with an `orgId IN [...]` constraint and 100% rollout               |
| Branding flickers between defaults and the override      | Branding can take a short time to appear after a payload change  | Wait briefly and check again                                                                          |

---

## Ingress

Source: https://docs.kindo.ai/deploy/ingress/

Kindo's hosts reach the cluster through your ingress controller and load balancer. You can route them in one of two ways:

- **Your own routing.** You create the Ingress objects, load-balancer rules, or gateway routes for each host. Print the hosts, backends, ports, and health checks with `kindo ingress manifest`.
- **Kindo-managed ingress.** Add an `ingress:` block to `install-contract.yaml`, and Kindo creates and manages an Ingress object for every host on each install and upgrade.

## App host routes

Use separate hostnames for the app and API. When the install contract enables ingress, the app hostname routes `/auth`, `/trpc`, and `/express` and their subpaths to the API. Other paths, including `/api/*`, reach the web app. `kindo install --apply` and `kindo upgrade --apply` create or update these routes; no manual ingress changes are needed.

## Allowlists

Kindo-managed ingress puts every host on one load balancer, and OAuth callbacks on `integrations-api.<domain>` and `/webhook` on `api.<domain>` must stay reachable from the internet. An allowlist set in the contract's `ingress.annotations`, such as `alb.ingress.kubernetes.io/inbound-cidrs`, applies to every host and blocks them. If you restrict your load balancer to an allowlist, keep your own routing.

## Move to Kindo-managed ingress

Make this change on its own, in a maintenance window, on an install that is already running its target version.

To go back, set `ingress.enabled: false`, run the same `kindo upgrade` command, and reapply `ingress-backup.yaml`.

---

## Operate

Source: https://docs.kindo.ai/deploy/operate/

Use these commands to operate a healthy install after [Configure & Validate](/deploy/configure-and-validate/).

:::note
Every command on this page expects a working `kindo-cli` installation and a `kubectl` context that points at the target cluster. Commands that use `install-contract.yaml` and `environment-bindings.yaml` read them from the current directory unless you pass `--contract` / `--bindings` explicitly.
:::

## CLI daily-drivers

| Command                                              | Purpose                                                                                  |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| `kindo status`                                       | Show install state and live release versions                                             |
| `kindo doctor`                                       | Read-only diagnosis of a degraded install                                                |
| `kindo config edit`                                  | Edit the cluster secrets config (credentials, service overrides) in `$EDITOR`            |
| `kindo config apply`                                 | Regenerate the per-app Secrets from the secrets config and restart the affected services |
| `kindo config validate --preflight`                  | Check the schema and infrastructure connectivity                                         |
| `kindo config override list \| set \| unset`         | Manage per-service environment-variable overrides                                        |
| `kindo config override edit \| diff \| apply`        | Edit overrides, preview changes, and apply them to the cluster                           |
| `kindo config helm-override list \| set \| unset`    | Manage Helm chart value overrides that persist across upgrades                           |
| `kindo config helm-override edit \| diff \| apply`   | Edit, preview, and apply persistent Helm chart value overrides                           |
| `kindo config backup`                                | Export the install's configuration and secrets to an encrypted bundle                    |
| `kindo restore <bundle>`                             | Restore an install from a backup bundle onto an empty cluster                            |
| `kindo config log-level set \| show \| unset`        | Set the log level for the Kindo applications                                             |
| `kindo db list`                                      | List the Postgres databases                                                              |
| `kindo db tunnel <database>`                         | Open a port-forward tunnel to a database                                                 |
| `kindo db prompt <database>`                         | Open an interactive `psql` session over a tunnel                                         |
| `kindo db reset [database]`                          | Drop all tables (destructive; resetting all databases requires two confirmations)        |
| `kindo integrations list`                            | Show available and enabled MCP integrations                                              |
| `kindo integrations enable <name>`                   | Enable an integration in the contract                                                    |
| `kindo integrations disable <name>`                  | Disable an integration in the contract                                                   |
| `kindo integrations apply`                           | Register and deploy enabled integrations                                                 |
| `kindo integrations bootstrap`                       | Re-run integration registration against the cluster                                      |
| `kindo integrations status`                          | Show live integration status from the cluster                                            |
| `kindo uninstall all \| applications \| peripheries` | Tear down a group of releases                                                            |

Register and review models in the superadmin dashboard at `https://superadmin.<domain>`.

### `kindo status`

Check install state:

```bash
kindo status
```

State is stored in the cluster, so any workstation with cluster access sees the same answer. The table has one row per install step. Anything other than `completed` on a fresh install means stop and investigate. After fixing the cause, resume from the failed step:

```bash
kindo install --resume
```

Below the table, a `Superadmin:` line shows `✓ bootstrapped`, `✗ not bootstrapped`, or `? unknown` with the reason. If it reports `✗ not bootstrapped`, run:

```bash
kindo install --step superadmin-bootstrap
```

Use `kindo status --no-live` to skip the live checks: the superadmin line and the live release/version table.

### `kindo config edit` and `kindo config apply`

Use these commands to change the cluster secrets config and restart affected services:

1. Run the pre-change check. It checks the schema and connectivity to Postgres, Redis, RabbitMQ, and object storage:

   ```bash
   kindo config validate --preflight
   ```

2. Open the secrets config:

   ```bash
   kindo config edit
   ```

   This loads the `kindo-secrets-config` Secret from `kindo-system`, opens it as YAML in `$EDITOR` (or `vi`), and saves it back. It includes sensitive values. The command checks only that the result is valid YAML and a mapping; **there is no schema validation, so a typo is saved as-is**. Saving does not restart services.

3. Regenerate each app's Secret and rolling-restart the affected deployments:

   ```bash
   kindo config apply
   ```

   To limit regeneration and restarts, pass a comma-separated list of app names with `--only`:

   ```bash
   kindo config apply --only api,next
   ```

   `kindo config apply` also accepts `--context` to select the cluster.

Service overrides win over the values Kindo generates. With an external secrets store, values in the store take precedence over the ones `kindo config apply` generates.

### Apply configuration changes

`kindo config edit` edits the secrets config, and `kindo config apply` reads that config only. Choose the apply command for the setting you changed:

| Change                                           | Apply with                                                               |
| ------------------------------------------------ | ------------------------------------------------------------------------ |
| Secrets config or service overrides              | `kindo config apply` or `kindo config override apply <service>`          |
| Helm chart values                                | `kindo config helm-override apply`                                       |
| Contract `ingress:` block                        | The next `kindo upgrade`                                                 |
| Contract SMTP settings or sandbox settings       | The next `kindo upgrade`                                                 |
| Contract `integrations:`                         | `kindo integrations apply`                                               |
| Reset every feature flag to the shipped defaults | `kindo install --step post-install`; reapply your flag changes afterward |

### `kindo config override`

Use service overrides to change environment variables, such as `SUPERADMIN_API_KEY_TTL_DAYS` or `NEXT_PUBLIC_NANGO_CONNECT_URL`. Overrides are stored under `serviceOverrides.<service>.

---

## Scaling and Tuning

Source: https://docs.kindo.ai/deploy/scaling-and-tuning/

Start from the defaults in [Choose a size](/deploy/provision-infrastructure/#1-choose-a-size). Watch usage in [HyperDX](/deploy/observability/) and check install health with [`kindo status`](/deploy/operate/#kindo-status) and [`kindo doctor`](/deploy/operate/#kindo-doctor), then adjust the services that need more or less capacity.

Make every change on this page with a [Helm override](/deploy/operate/#kindo-config-helm-override). Overrides persist across upgrades, so you set each one once.

## Scale a service

Add replicas or resources to a service that runs hot, and trim a service that sits well below its requests. For example, to let the `api` release autoscale and give each pod more memory:

1. Stage the settings:

   ```bash
   kindo config helm-override set api \
     autoscaling.enabled=true \
     autoscaling.minReplicas=2 \
     autoscaling.maxReplicas=4 \
     resources.requests.memory=2Gi
   ```

2. Preview and apply them:

   ```bash
   kindo config helm-override diff api
   kindo config helm-override apply api
   ```

3. Watch the service in HyperDX and adjust again if needed.

Set related values in the same `set` command. `set` rejects a path that has no effect on its own, such as `autoscaling.minReplicas` while autoscaling is off.

Add nodes when pods stay `Pending` after a change.

## Agent sandboxes

Each agent sandbox runs as a pod on a sandbox node, with its own 10 Gi volume. After 15 minutes without activity, a sandbox suspends: its pod stops and its volume stays. After 60 minutes without activity, the sandbox and its volume are deleted. A persistent workspace suspends the same way but keeps its volume until it goes 180 days without use, so sandbox storage grows with use.

Plan for about 60 concurrent sandboxes at Medium and 200 at Large. Each running sandbox also counts against the per-node volume attach limit in the [Kubernetes cluster requirements](/deploy/provision-infrastructure/#2-kubernetes-cluster). To support more concurrent sandboxes, add sandbox nodes.

To change the volume size or retention, set values on the `sandbox` release:

| Value                                                 | Default  | Sets                                                                                                        |
| ----------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------- |
| `openshell.gatewayConfig.workspaceDefaultStorageSize` | `10Gi`   | Volume size for each sandbox created after the change                                                       |
| `openshell.gatewayConfig.workspaceStorageClass`       | (empty)  | StorageClass for sandbox volumes; empty uses the cluster default                                            |
| `api.sandboxLifecycle.deleteAfterMinutes`             | `60`     | Minutes without activity before a sandbox and its volume are deleted                                        |
| `api.sandboxLifecycle.persistentDeleteAfterMinutes`   | `259200` | Minutes without use before a persistent workspace and its volume are deleted; at least `deleteAfterMinutes` |

A retention change applies to existing persistent workspaces.

For example, to give each sandbox a 20 Gi volume and keep persistent workspaces for 90 days:

```bash
kindo config helm-override set sandbox \
  openshell.gatewayConfig.workspaceDefaultStorageSize=20Gi \
  api.sandboxLifecycle.persistentDeleteAfterMinutes=129600
kindo config helm-override apply sandbox
```

A larger volume size also raises the block storage you need, so check that your StorageClass has room.

## PII analyzer

The PII analyzer runs one replica with 4 workers, requesting 2.5 CPU and 4 GiB of memory. Its memory use scales with the number of workers, so change workers and memory together.

To shrink it on a smaller install:

```bash
kindo config helm-override set presidio \
  analyzer.container.env.WORKERS=2 \
  analyzer.container.resources.requests.memory=2Gi \
  analyzer.container.resources.limits.memory=2Gi
kindo config helm-override apply presidio
```

To handle more PII detection traffic, raise workers and memory in the same proportion.

## Observability storage

ClickHouse stores telemetry on two 300 Gi volumes and keeps it for 7 days. To keep more or less history, change the retention period in [Signals and retention](/deploy/observability/#signals-and-retention).

To add space, expand the ClickHouse volumes. Your StorageClass must allow volume expansion. Volumes can grow but cannot shrink.

1. List the ClickHouse data volumes:

   ```bash
   kubectl -n clickhouse get pvc
   ```

2. Expand each `data-` volume to the new size, for example:

   ```bash
   kubectl -n clickhouse patch pvc <pvc-name> \
     -p '{"spec":{"resources":{"requests":{"storage":"500Gi"}}}}'
   ```

3. Confirm the new capacity:

   ```bash
   kubectl -n clickhouse get pvc
   ```

---

## Upgrade from 2026.07 to 2026.09

Source: https://docs.kindo.ai/deploy/upgrade-2026-09/

Follow this page from top to bottom to upgrade a Self-Managed Kindo install from 2026.07 to 2026.09. Plan a maintenance window with each organization's IdP administrator available: SSO sign-in fails until you restore SSO for each organization after the upgrade.

## Prepare

Complete these steps before the maintenance window.

## Update the configuration

## Upgrade

Run these steps in the maintenance window, from the directory holding `install-contract.yaml` and `environment-bindings.yaml`.

## Restore SSO for each organization

Create a SAML connection for each organization that uses SSO, and update its IdP application. Members of an organization that enforces SSO can't sign in until its connection works. Members of an organization without enforcement can use **Continue with email** in the meantime.

Restore SSO for your own organization last, and keep your superadmin dashboard session open until its SSO works. For each organization:

### Provider notes

**Okta**

- **Create the SAML connection:**
  - **Option 1, upload metadata:** on the Kindo application's **Sign On** tab, open the **Metadata URL** and save the page as an `.xml` file.
  - **Option 2, enter the values by hand:** from **More details** on the same tab:
    - **IdP Entity ID:** **Issuer**
    - **Redirect URL:** **Sign on URL**
    - **Signing certificate:** the full contents of `okta.cert`, from **Download** on the **Signing Certificate** row
- **Update the existing IdP application:** open **General** → **SAML Settings** → **Edit**. Set **Single sign-on URL**, **Recipient**, and **Destination** to the ACS URL, and **Audience URI (SP Entity ID)** to the SP Entity ID.

**Microsoft Entra ID**

- **Create the SAML connection:**
  - **Option 1, upload metadata:** download **Federation Metadata XML** from the Kindo application's **SAML Certificates** section.
  - **Option 2, enter the values by hand:**
    - **IdP Entity ID:** **Microsoft Entra Identifier**
    - **Redirect URL:** **Login URL**
    - **Signing certificate:** the full contents of the **Certificate (Base64)** download
- **Update the existing IdP application:** open **Single sign-on** and select **Edit** in **Basic SAML Configuration**. Set **Reply URL (Assertion Consumer Service URL)** to the ACS URL, and **Identifier (Entity ID)** to the SP Entity ID.

## Finish the upgrade

## Roll back to 2026.07

Kindo supports fixing forward: fix the cause of a failed upgrade and run `kindo upgrade --apply` again, which is safe to repeat.

If you can't fix forward and need to return to 2026.07:

---

## Upgrade

Source: https://docs.kindo.ai/deploy/upgrade/

Use `kindo upgrade` to preview and apply a Self-Managed Kindo release.

:::note[Upgrading from 2026.07]
Follow [Upgrade from 2026.07 to 2026.09](/deploy/upgrade-2026-09/).
:::

## Release cadence and versioning

Kindo ships monthly releases with calendar versions such as `2026.09.<n>`.

## Run the upgrade

Run every `kindo upgrade` command from the directory holding `install-contract.yaml` and `environment-bindings.yaml`.

### Preview the upgrade

```bash
kindo upgrade --version <target> --plan
```

The plan leaves your deployment unchanged. It shows what you need to check or act on: the prerequisite and cluster checks, chart availability at the target version, a reminder to back up after the upgrade when it generates new credentials, the running Helm values the upgrade resets (see [Helm customizations across upgrades](#helm-customizations-across-upgrades)), and configuration you must provide. Add `--verbose` to also see what the upgrade handles on its own, such as environment variable and feature flag changes and the upgrade steps.

The command exits non-zero when something blocks `--apply`: a missing `operatorEmail`, charts missing from the registry, an unwritable contract file, or required values missing from your secrets store. Fix every blocking issue and run the plan again. Save the plan output as a record.

### Apply the upgrade

```bash
kindo upgrade --version <target> --apply
```

Optional flags:

| Flag                            | Purpose                                                                                    |
| ------------------------------- | ------------------------------------------------------------------------------------------ |
| `--dry-run`                     | Preview Helm diffs.                                                                        |
| `--verbose`                     | Show raw output.                                                                           |
| `--no-test-email`               | Skip the preflight test email from `smtp.fromEmail` to `operatorEmail`, sent by default.   |
| `--readiness-timeout <seconds>` | Set how long to wait for the API to come up. The default is 600 seconds; 0 skips the wait. |

If the target release's infrastructure checks fail, the upgrade stops before changing any release. One of the checks sends a real email to `operatorEmail`; see [SMTP test email](/deploy/install-with-kindo-cli/#3-preflight-your-infrastructure).

When the install needs its first superadmin, the upgrade creates the account for `operatorEmail` and prints its key once. Store the key; it is not shown again. If a superadmin already exists, it confirms this with `already bootstrapped`.

Success prints `Upgrade to <version> complete!`. The `Superadmin:` line says whether the account was created or already existed. If it says `not independently verified`, check the account status:

```bash
kindo status
```

Once the API is up on the target version, the install records that version, including when a later part of the upgrade fails.

If the run completes with warnings, fix the reported cause and run the command named in the warning:

```bash
kindo install --step integrations
```

Or, for a feature flag warning:

```bash
kindo install --step sync-flags
```

If superadmin setup fails, the run prints `Upgrade to <version> did not complete: superadmin-bootstrap failed`. Recover by fixing the cause and running these commands in order:

```bash
kindo install --step superadmin-bootstrap
kindo install --step integrations
```

## Helm customizations across upgrades

Keep Helm customizations in `kindo config helm-override` to preserve them through every upgrade. The upgrade applies the target release's values plus your Helm overrides. A value set another way, such as through `helm upgrade --set`, stops applying at the next upgrade.

Both `--plan` and `--apply` (before it starts making changes) list, under **Helm Values**, each running value the target release resets that you may have set. Each entry shows the release, path, and running value. Earlier releases' defaults are counted rather than listed; add `--verbose` to list them. Credential values appear as `(hidden)`. The list excludes secret and environment blocks, global and ingress values, and Kindo image tags, which Kindo sets.

To keep a value you set on purpose, such as replica counts, resources, or node placement:

1. Save it as a Helm override before running `--apply`:

   ```bash
   kindo config helm-override set <release> <path>=<value>
   ```

2. Run `--plan` again to review the result.

The upgrade applies the saved override.

When the contract's `ingress:` block is enabled, each upgrade applies its hosts and edge settings. Change those settings in the contract; per-release `ingress.annotations` values saved with `kindo config helm-override` survive upgrades. Direct edits to an Ingress object created by the CLI are replaced at the next upgrade.

The same applies to any other Kindo-managed object: an upgrade resets a field the chart sets to the chart's value, even if you or another tool changed it directly, for example with `kubectl edit` or `kubectl patch`. To keep such a change, save it before upgrading with `kindo config helm-override`, or with `kindo config override` for a service environment variable.

## Per-application secrets on upgrade

On the default Kubernetes secrets backend, `kindo upgrade` regenerates each application's secrets from the saved configuration. Overrides set with `kindo config override set` and values set in the contract survive the upgrade unchanged.

If the target version requires a secret that you supply, such as an OAuth client secret, the Kubernetes backend prompts for it before continuing. The value is saved and reused on subsequent upgrades.

### External secrets store

Values in an external secrets store take precedence. Before making changes, the upgrade checks that every required value is available from the store or supplied by Kindo. If values are missing, add them to the store and run the upgrade again. Supply new keys directly in the external store before upgrading; prompts for new keys are available only on the Kubernetes backend.

## Upgrade without local config files

When `install-contract.yaml` or `environment-bindings.yaml` is missing from the current directory, the CLI asks `Reconstruct from live deployment?`.

## If an upgrade was interrupted

## Rollback

:::caution[Prefer fixing forward]
Fix the cause of a failed upgrade, then repeat `kindo upgrade --apply`, which is safe to repeat. For a superadmin setup failure, use the recovery commands under [Apply the upgrade](#apply-the-upgrade).
:::

To return to the previous release, restore the pre-upgrade configuration backup and database snapshots onto an empty cluster:

## Pre-upgrade checklist

Complete every item before applying an upgrade:

| Check                                     | How                                                                                               |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Configuration backup taken                | Run `kindo config backup` and store the encrypted bundle and passphrase.                          |
| Database snapshots current and restorable | Snapshot every Postgres instance Kindo uses.                                                      |
| Cluster health clear                      | Resolve every critical finding from `kindo doctor`.                                               |
| Upgrade plan clear                        | Run `kindo upgrade --plan`; resolve every blocking issue and confirm a successful exit.           |
| Helm customizations saved                 | Keep required values in `kindo config helm-override`.                                             |
| CLI matches the target release            | Check `kindo --version`.                                                                          |
| Registry egress open                      | Allow access to `registry.kindo.ai`.                                                              |
| Maintenance window scheduled              | Reserve time for the upgrade and smoke tests.                                                     |
| Other configuration operations finished   | Wait for every other `kindo install`, `kindo upgrade`, or `kindo config apply` session to finish. |

## Post-upgrade checklist

| Check                               | How                                                                        |
| ----------------------------------- | -------------------------------------------------------------------------- |
| Target version and healthy releases | Check `kindo status`.                                                      |
| All pods Ready                      | Run the [pod health check](/deploy/configure-and-validate/#52-pod-health). |
| Cluster health clear                | Resolve every critical finding from `kindo doctor`.                        |
| Smoke tests pass                    | Follow [Configure & Validate](/deploy/configure-and-validate/).            |
| Observability at baseline           | Check dashboards for expected error rates, latency, and resource use.      |

## Next steps

---

## Admin and Security

Source: https://docs.kindo.ai/admin/

Configure and manage Kindo's security, identity, and governance features.

## Common Tasks

---

## Single Sign-On (SSO) Setup

Source: https://docs.kindo.ai/admin/sso/

Single Sign-On (SSO) connects your identity provider (IdP) to Kindo through SAML. **Settings** → **SSO** appears under **Organization** for organization **Admins**. Each organization has one SAML connection.

:::caution[Verified domain required]
Your organization needs a verified email domain to create a SAML connection. If a domain is missing, Kindo shows: “Your organization has no SSO email domain configured. Contact support to configure one.”

Ask your Kindo administrator to add and verify your organization's email domain, then retry.
:::

## Configure SSO for an organization

See [Cross App Access](/admin/cross-app-access/) (beta) to let an Okta-approved app call Kindo's MCP gateway on a user's behalf, on top of this SAML connection.

## SAML attributes

Use these exact attribute names. Leave the namespace blank.

| Attribute   | Requirement                                                 | Value                                                                 |
| ----------- | ----------------------------------------------------------- | --------------------------------------------------------------------- |
| `email`     | Required unless the SAML Name ID contains the email address | The user's Kindo email address on your organization's verified domain |
| `givenName` | Optional, recommended                                       | The user's first name                                                 |
| `surname`   | Optional, recommended                                       | The user's last name                                                  |

Kindo reads the email address from `email`, with the SAML Name ID as a fallback. If you send both, use the same email address.

Send `givenName` and `surname` to populate the user's display name. The display name falls back to `displayName`, then the Name ID.

## Identity provider guides

- [Microsoft Entra ID](/admin/sso-entra/)
- [Okta](/admin/sso-okta/)

### ADFS example

## How users sign in

You can also select the Kindo application tile in your identity provider. Both paths return you to Kindo.

Kindo creates an account on a user's first SSO sign-in when their email address uses the organization's verified domain. This is just-in-time provisioning.

## Require SSO

Configure **IdP Entity ID**, **Redirect URL**, and **Signing certificate** before enabling enforcement. With **SSO Enforcement** enabled, organization members must use SSO for sign-in.

---

## SAML with Microsoft Entra ID

Source: https://docs.kindo.ai/admin/sso-entra/

Before you configure Entra, create your organization's SAML connection in Kindo under **Settings** → **SSO**. You must be an organization **Admin**. Follow [Single Sign-On (SSO) Setup](/admin/sso/) and keep the **ACS URL** and **SP Entity ID** available.

## Create or update the Entra application

For an existing Kindo application, open it and continue with the SAML configuration below.

To create an application:

Configure SAML for the application:

The recommended `givenName` and `surname` claims populate the user's display name. For claim options, see [Customize SAML token claims](https://learn.microsoft.com/en-us/entra/identity-platform/saml-claims-customization).

## Add Entra details in Kindo

Use metadata XML to import the IdP settings:

For manual configuration:

## Assign users and test

Users must be assigned to the Entra application to sign in.

---

## SAML with Okta

Source: https://docs.kindo.ai/admin/sso-okta/

Before you configure Okta, create your organization's SAML connection in Kindo under **Settings** → **SSO**. You must be an organization **Admin**. Follow [Single Sign-On (SSO) Setup](/admin/sso/) and keep the **ACS URL** and **SP Entity ID** available.

## Create or update the Okta application

For an existing Kindo application, open it and edit its SAML settings. Skip the creation steps and continue with the SAML configuration below.

To create an application:

Configure SAML for the application:

For field details, see the [Okta SAML application reference](https://help.okta.com/en-us/content/topics/apps/aiw-saml-reference.htm).

## Add the Okta details in Kindo

Use metadata XML to import the IdP settings:

For manual configuration:

## Assign users and test

Users must be assigned to the Okta application to sign in.

---

## Security Controls

Source: https://docs.kindo.ai/admin/security-controls/

Kindo maintains security, auditing, and compliance controls to ensure users and agents operate within organizational requirements. Access these controls via [**Settings** (gear icon) > **Organization > Model Access & DLP**](https://app.kindo.ai/?settings=model-access-and-dlp).

:::note
You must be an Administrator to access these Organization settings.
:::

## Model Access & DLP

![The Model Access & DLP panel showing providers, models, enabled status, and DLP filter toggles](../../../assets/docs/security-controls/model-access-dlp-controls.png)

This section manages which AI models are enabled for your organization.

- **Active** -- Users can access the model; agent and API requests succeed.
- **Disabled** -- The model is hidden from users; agent and API requests to it will fail.

You can also enable or disable DLP filters for specific models and manage model versions from this screen.

### Default Settings

![Default settings for new provider and new model behavior](../../../assets/docs/security-controls/default-settings.png)

Configure default behavior when new models are added:

- **New Provider** -- Whether adding new model providers is permitted in your organization.
- **New Models of Enabled Providers** -- Whether new models from an already-enabled provider are activated by default.

### Data Loss Prevention (DLP) Filters

![The DLP Filters panel showing built-in filter types](../../../assets/docs/security-controls/dlp-filters.png)

DLP filters are redaction mechanisms that tokenize sensitive data in outbound requests to AI models. When enabled, sensitive information is automatically masked in chat, agent, and API calls before reaching the model.

Kindo includes several built-in DLP filter types. You can also define custom filter patterns using:

![Creating a custom DLP filter with string literal, phrase, or regex options](../../../assets/docs/security-controls/dlp-custom-filter.png)

- **String literals** -- Exact text matches
- **Phrases** -- Multi-word patterns
- **Regular expressions** -- Pattern-based matching

## Integration Access

![The Integration Access panel with Active/Off toggles for each integration](../../../assets/docs/security-controls/integration-access.png)

Control which integrations are available to users:

- **Active** -- Users can use the integration to connect with external systems.
- **Off** -- The integration is unavailable to users in the organization.

For per-user-group overrides and per-tool granularity, see [Tool Action Access Controls](/admin/rbac-tool-actions/). For the enterprise pattern of isolating an integration to a single team (e.g., legal, finance), see [Integration Identity Isolation](/admin/integration-trust-domains/).

## Audit Log

Kindo records audit events whenever users, AI agents, or administrators perform actions within the platform. These events are retained in a log to provide a record of activity for security review, compliance, and incident investigation. Audit logging is available to organizations on the Enterprise plan.

### What the Audit Log Captures

Every audit event includes a timestamp, the acting user, the organization, and structured metadata. Events fall into three categories:

- **User actions** — Chat messages, file uploads, workflow management, connecting and disconnecting integrations, API key and secret management, copilot activity
- **AI agent actions** — Tool executions (success/failure), LLM requests, sandboxed code execution, DLP filter events
- **Administrative changes** — Member and invite management, user group changes, security configuration updates, model management, organization settings

<details>
<summary>Full event type reference</summary>

**User actions:** Creating chats, sending messages, sharing conversations, uploading/removing files, creating/updating/deleting workflows, connecting and disconnecting integrations, managing API keys and secrets, copilot usage, viewing and exporting audit logs.

**AI agent actions:** Successful and failed tool calls, LLM inference requests, sandboxed code runs, DLP filter redactions, automated API step generation in workflows.

**Administrative changes:** Adding/removing/changing roles for members, managing invitations, creating/updating/deleting user groups, updating security settings, configuring tool servers, managing sharing permissions, creating/deleting DLP patterns, adding/removing models, changing organization settings, and [Cross App Access](/admin/cross-app-access/) configuration and client actions — saving or deleting the configuration, creating or revoking a client, and approving a CIMD client.

Each Cross App Access token issued or denied is also logged, but as a system event with no acting user — it isn't attributed to an admin or end user, so it's excluded when filtering the log to user-initiated events. A token is logged as denied only once the organization is identified; an earlier failure (invalid client credentials, a malformed assertion, a missing or unrecognized audience tenant ID, or an untrusted issuer) is recorded only in server logs.

</details>

### Viewing Events

![The Audit Log panel showing recent user activity](../../../assets/docs/security-controls/audit-log.png)

Navigate to [**Settings > Organization > Audit Log**](https://app.kindo.ai/?settings=audit-log) to view events.

![Audit log with filters applied for user and activity type](../../../assets/docs/security-controls/audit-log-filters.png)

Filter by:

- **User** — Events from a specific user
- **Activity type** — Filter by event category or specific event type
- **Date range** — Narrow results to a specific time window

### Event Details

Click any event row to view its full details:

![An audit log event detail showing the event summary](../../../assets/docs/security-controls/audit-log-event-detail.png)

- **Summary** — Human-readable description of the action
- **Raw Data** — Full JSON payload including files accessed, metadata, and contextual information

### Exporting Events

Click **Download CSV** to export filtered events. Kindo generates the CSV asynchronously and emails a download link to you. The link expires after a set period.

### Storage

Audit events are written to Kindo's application database by default — no additional configuration required. Events are queryable in the admin UI and exportable as CSV.

### Troubleshooting

**Events not appearing** — Confirm the organization is on the Enterprise plan and that the `AUDIT_LOG_DISABLED` feature flag is not enabled in Unleash.

**CSV export email not received** — Verify SMTP is configured correctly on the Kindo API service and that the requesting user's email address is correct.

## Sharing Permissions

![The Sharing Permissions panel with external sharing toggle and minimum role setting](../../../assets/docs/security-controls/sharing-permissions.png)

Control whether users can share agents or chats with individuals outside the organization:

- When **External Sharing** is **Active**, configure the minimum user role required for sharing.
- When **External Sharing** is disabled, users cannot share links to chats or agents with anyone outside their configured identity provider.

---

## User Groups

Source: https://docs.kindo.ai/admin/user-groups/

User Groups let you manage permissions for teams in your organization. By organizing users into groups, you can efficiently manage security policies and access controls across integrations, models, DLP, and platform features.

:::note
You must be an Administrator to create and manage user groups.
:::

## Access Control Rules

User groups follow two core principles:

1. **Organization settings are the baseline** -- Group settings cannot override organization-level restrictions. If the organization disables something, no group can re-enable it.
2. **Permissions are additive across groups** -- When a user belongs to multiple groups, they receive the combined permissions of all their groups. If one group grants access and another restricts it, access is granted.

Administrators are exempt from all user group restrictions and always have full access.

## Permission Areas

User groups control five areas:

| Area | What it governs |
|------|----------------|
| [Integration access](#integration-access) | Which integrations users can connect and use |
| [Model and provider access](#model-and-provider-access) | Which AI models users can access |
| [DLP enablement and configuration](#dlp-enablement-and-configuration) | Whether DLP filters apply and how they are configured |
| [Tool action access](#tool-action-access) | Which specific tool actions are available per integration |
| [Feature permissions](#feature-permissions) | Platform capabilities like agent creation, file upload, and API key access |

## Creating a User Group

## Managing Group Members

From the **Members** tab of a user group, administrators can:

- Add individual members via the dropdown selector
- Add multiple members by entering comma-separated email addresses
- Remove members from the group

## Integration Access

Organization-level integration settings are the ceiling. If an organization disables an integration, no users can access it regardless of group membership.

### How Group Memberships Affect Access

When a user belongs to multiple groups, they get access to all integrations from all their groups.

**Example:**

- Organization has access disabled for Jira
- User A belongs to "IT" and "Analytics" groups
- IT group has access to Slack, but access is disabled for Google Drive
- Analytics group has access to Google Drive and ServiceNow
- **Result:** User A gets access to Slack, Google Drive, and ServiceNow

For fine-grained control over specific tool actions within an integration, see [Tool Action Access Controls](/admin/rbac-tool-actions/).

## Model and Provider Access

Organization-level model settings are the ceiling. If an organization disables a model or provider, no users can access it regardless of group membership.

### How Group Memberships Affect Access

When a user belongs to multiple groups, they get access to all models from all their groups.

**Example:**

- Organization has access disabled for Claude 3.5 Sonnet
- User A belongs to "Research" and "Engineering" groups
- Research group has access enabled for GPT-4, but access disabled for Claude 3 Opus
- Engineering group has access enabled for Claude 3 Opus, but access disabled for Llama 3
- **Result:** User A gets access to GPT-4 and Claude 3 Opus

For managing which models are available organization-wide, see [Security Controls -- Model Access](/admin/security-controls/#model-access--dlp).

## DLP Enablement and Configuration

Data Loss Prevention (DLP) filters redact sensitive data before it reaches AI models. DLP settings operate at two levels: **enablement** (whether DLP is active for a model) and **configuration** (which patterns are redacted).

### DLP Enablement

**Organization level:**

- If DLP is enabled for a provider, then DLP can be enabled for individual models under that provider.
- If DLP is disabled for a provider, none of its models can have DLP enabled.

**User group level:**

- If the organization has disabled DLP for a model or provider, user groups cannot enable it.
- If the organization has enabled DLP and any of the user's groups has DLP enabled for that model, DLP is active for that user.

### DLP Configuration Cascade

DLP configuration follows an override hierarchy. More specific settings override broader ones:

**Organization level:**

1. A model-specific custom DLP configuration overrides both the provider configuration and the organization's base configuration.
2. A provider-specific custom DLP configuration overrides the organization's base configuration.

**User group level:**

1. A model-specific custom DLP configuration for a user group overrides both the provider configuration and the group's base configuration.
2. A provider-specific custom DLP configuration for a user group overrides the group's base configuration.
3. The user group's final configuration is always **combined** with the organization's configuration, applying the **most restrictive rule** from each. This also holds when a user belongs to multiple groups.

**Example:**

- Organization has custom DLP configuration for GPT-4 (only "NRP" redacted)
- User A belongs to "Research" and "Engineering" groups
- Research group has custom DLP configuration for Azure (GPT-4's provider, only "Location" redacted)
- Engineering group has no custom DLP configuration, but its base DLP configuration redacts "IP Address"
- Organization, Research group, and Engineering group all have DLP enabled for GPT-4
- **Result:** When User A uses GPT-4, the following patterns are redacted: NRP (from organization), Location (from Research group), IP Address (from Engineering group)

For more on DLP filter types and custom patterns, see [Security Controls -- DLP Filters](/admin/security-controls/#data-loss-prevention-dlp-filters).

## Tool Action Access

User groups can control which specific tool actions are available per integration, beyond simple integration-level enable/disable. This includes restricting agents to read-only operations, scoping access by team, and enforcing least privilege.

For the full configuration guide, examples, and troubleshooting, see [Tool Action Access Controls](/admin/rbac-tool-actions/).

## Feature Permissions

Feature permissions control platform capabilities for group members. These are configured on the **Permissions** tab of a user group.

Admins are exempt from all feature permission restrictions and always have full access regardless of group membership.

| Permission | Default | Description |
|------------|---------|-------------|
| **Ask Mode Only** | Off | Restricts members to Ask mode only -- disables Actions mode. Enforced on both the frontend and backend (including the Responses API). |
| **Allow Agent Creation** | On | Controls whether members can create, duplicate, or save agents. |
| **Chat Messaging** | On | Controls whether members can send chat messages. When disabled, members cannot start new conversations, send follow-up messages, or type in the prompt bar. Members can still browse and run shared agents -- the only messages that can be sent are those predefined via an agent step. |
| **File Upload** | On | Controls whether members can upload files. |
| **Personal API Key Access** | Off | Controls whether members can create personal API keys and whether those keys are valid at runtime. Model and provider access restrictions from user groups still apply to API requests. Ask Mode Only is still enforced on the Responses API. Does not affect admin-created API keys. |
| **Show Agents Tab** | On | Controls whether the Agents tab is visible in the sidebar. |

### How Group Memberships Affect Feature Permissions

When a user belongs to multiple groups, the most permissive setting wins:

- **Ask Mode Only** -- The user is only restricted if **all** their groups enforce it. If any group has it off, the user can use Actions mode.
- **Allow Agent Creation** -- The user can create agents if **any** of their groups allows it.
- **Chat Messaging** -- The user can send chat messages if **any** of their groups allows it. API key access is not restricted by this permission.
- **File Upload** -- The user can upload files if **any** of their groups allows it.
- **Personal API Key Access** -- The user can create and use personal API keys if **any** of their groups enables it. Admin-created API keys are always valid regardless of this setting.
- **Show Agents Tab** -- The user sees the Agents tab if **any** of their groups shows it.

**Example:**

- User A belongs to "Restricted" and "Power Users" groups
- Restricted group has Ask Mode Only **enabled** and Allow Agent Creation **disabled**
- Power Users group has Ask Mode Only **disabled** and Allow Agent Creation **enabled**
- **Result:** User A can use Actions mode and create agents, because the Power Users group grants both permissions

:::caution
Disabling **Personal API Key Access** takes effect immediately. Any existing API keys created by affected members will stop working on the next API request. Before toggling this setting off, ensure affected users are aware that their active API integrations will break. This does not affect API keys created by admins on behalf of users.
:::

## Next Steps

- [Security Controls](/admin/security-controls/) to manage model access, DLP filters, and audit logging
- [Tool Action Access Controls](/admin/rbac-tool-actions/) for fine-grained integration and tool permissions
- [Governance and Controls](/features/governance/) for an overview of Kindo's governance framework

---

## Departments

Source: https://docs.kindo.ai/admin/departments/

:::note[Beta]
Departments are in beta for Enterprise organizations and are enabled per organization. To request access, contact your Kindo account team.
:::

Departments group the members of your organization for budgeting. Each member belongs to at most one department, so their spend counts toward exactly one department, and you can set a monthly budget on each department in [Budgets](/admin/budgets/).

Only organization administrators can create, rename, and archive departments and assign members to them. Other users who can open the members table see each member's department but cannot change it.

## Departments and User Groups

Departments and [user groups](/admin/user-groups/) both group the people in your organization, but they do different jobs and do not affect each other.

| | Departments | User Groups |
| --- | --- | --- |
| **Used for** | Budgeting: which department a member's spend counts toward. | Access control: what members can use and do. |
| **Membership** | At most one department per member. | Any number of groups per member. |
| **Controls** | None. A department grants no permissions, model access, DLP settings, or tool access. | Integration access, model access, DLP, tool actions, and feature permissions. |
| **Budgets** | Each department can have a monthly budget. | Groups cannot have budgets. |

Use user groups to decide what people can do, and departments to decide whose budget their spend counts toward. Changing a member's department does not change their access, and changing their groups does not change their department.

Budgets are set on departments rather than user groups because a member can belong to several groups. A budget on each group would count that member's spend several times, and group totals would not add up to your organization's spend. With one department per member, each dollar counts toward at most one department, so department totals never double-count.

## How Departments Work

- A department is a name. Apart from its budget, which you set in the Budgeting tab, it has no settings.
- A member belongs to one department or none. Assigning a member to a department moves them out of any department they were in.
- Members without a department show as **No Department**. Their spend counts toward no department budget.
- Spend counts toward the department the member belongs to when the spend is recorded. Changing a member's department applies going forward: spend already recorded stays with the department it was recorded under.

## The Departments Tab

The **All Departments** table lists your organization's departments by name, with a **HEADCOUNT** of the members in each. Archived departments do not appear.

### Create a Department

Department names must be unique among your organization's departments. Names are case-sensitive, so `Sales` and `sales` are different names.

### Rename a Department

Select the department's name, or the pencil icon on its row, and edit the name. The new name saves when you press **Enter** or select outside the field. Clearing the name leaves it unchanged.

### Archive a Department

Archiving removes the department from the Departments tab and from department pickers, and its members move to **No Department**. Spend already recorded for the department stays with it. The name becomes available for a new department.

Archiving cannot be undone.

## Assign Members to Departments

Assign members from the members table in your organization settings. A department must exist before you can assign members to it.

The change saves as soon as you choose. If the member was in another department, they move to the new one.

To filter the table by department, use **Department** above the table. Choose **No Department** to find members who still need one.

### Assign Several Members at Once

The confirmation shows how many of the selected members will move from another department and how many are already in the one you chose. Members already in that department are left unchanged. To clear the selection without assigning, select **Clear**.

To remove members from their department, change each one to **No Department** in the **Department** column.

## Department Budgets

In **Command Center** > **Budgeting**, select **Departments** to set a monthly warning amount for each department, or a default for every department without its own. The Budgeting tab is part of the [Budgets](/admin/budgets/) beta, which is enabled for your organization separately. See [Department Budgets](/admin/budgets/#department-budgets) for the panel and [Department Spend](/admin/budgets/#department-spend) for what counts toward a department.

## Audit Log

Department activity appears in the [audit log](/admin/security-controls/#audit-log):

| Event | Recorded when |
| --- | --- |
| **Department Created** | An administrator creates a department. |
| **Department Renamed** | An administrator changes a department's name. |
| **Department Archived** | An administrator archives a department. |
| **User Department Changed** | A member is assigned to a department, moved to another, or left without one, including when their department is archived or they leave the organization. One event is recorded per member. |

## Troubleshooting

| Problem | What to check |
| --- | --- |
| The Departments tab does not appear | Departments are in beta and enabled per organization for Enterprise organizations, and the tab is visible only to organization administrators. Contact your Kindo account team to request access. |
| A department name is rejected | Another department already uses that name. Rename or archive that department first. |
| **Set department** is disabled | Your organization has no departments yet. Create one in the Departments tab first. |
| A department is missing from a picker | Archived departments do not appear in pickers or in the Departments tab. |

## Next Steps

- [Set department budgets](/admin/budgets/#department-budgets)
- [Manage access with user groups](/admin/user-groups/)
- [Review the audit log in Security Controls](/admin/security-controls/#audit-log)

---

## Budgets

Source: https://docs.kindo.ai/admin/budgets/

:::note[Beta]
Budgets are in beta for Enterprise organizations and are enabled per organization. Department budgets also need [Departments](/admin/departments/), which are in beta and enabled separately. To request access, contact your Kindo account team.
:::

Budgets let organization administrators track AI model spend by agent and by department against monthly amounts they set. Set a warning amount in US dollars, and Kindo emails every administrator in your organization when spend for the month reaches it.

Budgets currently send alerts only: reaching a warning amount does not stop, slow, or change any runs. Blocking spend at a limit will be added shortly.

## How Budgets Work

| Budget type | What it tracks |
| --- | --- |
| [Agent budgets](#agent-budgets) | The spend of one agent your organization owns. |
| [Department budgets](#department-budgets) | The combined spend of the members of one department. |

Each budget has an amount that Kindo compares with its spend for the month:

| Amount | When spend reaches it |
| --- | --- |
| **Warning at** | Kindo emails every organization administrator. Runs continue as usual. |

### Spend Checks

Kindo checks spend against warning amounts about every 2 minutes, not after each model request. An alert can therefore arrive a few minutes after spend reaches a warning amount. Runs keep adding spend in the meantime, so spend may already be above the amount when the email arrives.

If you save a warning amount that spend has already reached, the alert is sent at the next check, unless the budget already alerted at that amount this month (see [One Alert per Amount](#one-alert-per-amount)).

### Defaults and Own Amounts

Each budget type has its own default that applies to everything of that type without its own amount, so one setting covers them all and you adjust only the exceptions. The agent default applies only to agents, and the department default only to departments.

| Setting | Meaning |
| --- | --- |
| **Default warning at** | The warning amount for everything of that type without its own. There is no default until you set one. |
| **Own amount** | A warning amount set on a single budget, such as one agent or one department. It replaces the default and can be higher or lower. |
| **No limit** | No warning amount. It never alerts, even when a default is set. |

### Monthly Window

Spend accumulates over the calendar month and resets on the 1st of each month (UTC). Warning amounts apply to each month separately, so a budget that alerted last month can alert again this month.

### One Alert per Amount

A budget alerts once for each warning amount each month. If you change the amount, higher or lower, the budget can alert again when spend reaches the new amount. Setting it back to an amount it already alerted at this month does not send another alert. Neither does switching between the budget's own amount and a default of the same amount.

## What Counts as Spend

Spend is the cost of AI model usage, in US dollars. It is measured separately from your organization's Kindo credit balance.

Spend counts usage of Kindo-provided models. Usage of self-managed models is not included currently, but will be added shortly.

### Agent Spend

An agent's spend includes the model requests it makes while it runs and in conversations with the agent. Background requests made on an agent's behalf do not count, such as generating its title and description, helping build it in the agent builder, or checking whether a trigger should run it.

### Department Spend

A department's spend includes its members' model requests: chats, agent runs, API requests, and background requests such as generating titles or helping build agents in the agent builder. Unlike agent spend, it is not limited to an agent's own requests. Checking whether a trigger should run an agent does not count.

- Requests count toward the department of the member they run as. An agent run started by a schedule, a webhook, or an event from a connected integration runs as the agent's creator, so it counts toward the creator's department.
- Each request counts toward the member's department at the time its spend is recorded. Moving a member to another department applies going forward; spend already recorded stays with the department it was recorded under.
- Spend by members with no department counts toward no department budget.
- Spend that counts toward an agent's budget also counts toward the department budget of the member the agent runs as.

## The Budgeting Tab

The Budgeting tab is visible only to organization administrators. Other users do not see budgets or spend amounts.

The tab has a panel for each budget type. Every panel has a **Default warning at** field and these columns:

| Column | What it shows |
| --- | --- |
| **Spend** | Spend this month. When a warning amount is set, a bar shows spend against it and changes color once spend reaches it. Spend is recalculated about every 2 minutes; **Calculating spend** appears until the first calculation finishes. |
| **Warning at** | The row's warning amount, which you can edit in place. A row using the default shows the default with **(Default)**, for example `$1,000 (Default)`, or **No limit (Default)** when no default is set. |

Use the tabs above the table to narrow the list:

| Tab | Rows shown |
| --- | --- |
| **All agents** or **All departments** | Every row. |
| **No budget** | Rows with no warning amount, either their own or from the default. |
| **Warn threshold** | Rows with a warning amount, either their own or from the default. |

Search by name, and sort by name, spend, or warning amount. The list is sorted by spend, highest first, when you open it.

### Set a Default Warning Amount

Every row without its own amount then warns at the default. Any of those that have already reached the default amount this month trigger an alert email within a few minutes, unless one was already sent for that amount (see [Spend Checks](#spend-checks)).

To remove the default, select the **X** in **Default warning at**. Rows that were using the default then have no warning amount.

### Set a Warning Amount

Enter an amount in a row's **Warning at** field, then press **Enter** or select outside the field. The amount saves as soon as you leave the field.

If spend this month has already reached that amount, Kindo shows **Spend already reaches this amount** before saving. Select **Set anyway** to save it. An alert email follows within a few minutes, unless one was already sent for that amount (see [Spend Checks](#spend-checks)).

To set **No limit**, select the **X** in the row's **Warning at** field, or clear the field. The field shows **No limit** in red, and the row never alerts, even when a default is set. To return it to the default, select the reset icon that replaces the **X**.

### Update Several Rows at Once

A change applies only to the selected rows the table shows. Once it is saved, those rows are unchecked. Selected rows hidden by a tab, search, or filter are not changed and stay selected. To clear the selection without making a change, select **Clear** in the bar.

You can change up to 1,000 rows at once; with more selected, **Update**, **Set no limit**, and **Reset to default** are disabled. A change applies to every selected row or to none of them: if a selected agent was deleted, or a selected department archived, after the list loaded, nothing changes, Kindo shows an error, the selection stays, and the list refreshes without it.

## Agent Budgets

The **Budgeting For Agents** panel lists every agent your organization owns. Along with **Spend** and **Warning at**, it shows:

| Column | What it shows |
| --- | --- |
| **Agent name** | The agent. Select the name to open the agent in the agent builder, or hover over the info icon to read its description. |
| **Creator** | The email address of the user who created the agent. Filter the list with **Creator**. |

Agents shared with your organization from another organization do not appear in the panel.

## Department Budgets

The **Budgeting For Departments** panel lists every department in your organization that is not archived. Along with **Spend** and **Warning at**, it shows:

| Column | What it shows |
| --- | --- |
| **Department** | The department's name. |
| **Headcount** | The number of members in the department. |

Archived departments are not checked against warning amounts. Spend by members without a department does not appear either. To create departments and assign members, see [Departments](/admin/departments/).

## Alert Emails

When spend for the month reaches a budget's warning amount, Kindo emails every administrator in your organization. Each administrator receives a separate email, usually within a few minutes of the spend being recorded, because spend is checked about every 2 minutes (see [Spend Checks](#spend-checks)).

The email subject is **Kindo spend limit warning:** followed by the budget's name. The email contains:

- **Spend limit**: the name of the agent or department that reached its warning amount.
- **Agent created by**: on agent alerts, the name and email address of the agent's creator.
- **Warning threshold**: the warning amount.
- **Spend to date**: the spend this month when it reached the amount.
- **Current window ends**: the last day of the month, after which spend resets.

Each budget alerts once per warning amount each month (see [One Alert per Amount](#one-alert-per-amount)). Alert emails need no setup and cannot be turned off per administrator.

### Audit Log

Budget activity appears in the [audit log](/admin/security-controls/#audit-log):

| Event | Recorded when |
| --- | --- |
| **Spend Limit Created**, **Spend Limit Updated**, **Spend Limit Deleted** | An administrator sets, changes, or removes a warning amount, including a default. |
| **Spend Limit Alert Triggered** | Spend reaches a warning amount. |
| **Spend Limit Alert Email Sent** | An alert email is sent to an administrator, one event per recipient. |

## Troubleshooting

| Problem | What to check |
| --- | --- |
| The Budgeting tab does not appear | Budgets are in beta and enabled per organization, and the tab is visible only to organization administrators. Contact your Kindo account team to request access. |
| **Departments** does not appear in the Budgeting tab | Department budgets need [Departments](/admin/departments/), which are in beta and enabled per organization. Contact your Kindo account team to request access. |
| An agent is missing from the list | The list shows agents your organization owns. Agents shared with your organization from another organization do not appear. |
| A department is missing from the list | Archived departments do not appear. |
| No alert email arrived | Check that **Spend** has reached the warning amount; spend is recalculated about every 2 minutes (see [Spend Checks](#spend-checks)). Check your spam folder, and look for **Spend Limit Alert Triggered** in the audit log. A budget alerts once per amount each month (see [One Alert per Amount](#one-alert-per-amount)). |
| An alert arrived soon after setting an amount | Spend had already reached that amount this month, including when a row was returned to a default it had already reached. |
| An agent's spend is lower than expected | Only the agent's own model requests on Kindo-provided models count. See [Agent Spend](#agent-spend). |
| A department's spend is lower than expected | See [Department Spend](#department-spend) for which requests count and when a member's spend counts toward a department. |

## Next Steps

- [Create and manage agents](/features/creating-agents/)
- [Group members into departments](/admin/departments/)
- [Review governance and controls](/features/governance/)
- [Review the audit log in Security Controls](/admin/security-controls/#audit-log)

---

## Enterprise Application Permissions

Source: https://docs.kindo.ai/admin/enterprise-app-permissions/

When connecting Kindo to Microsoft services, each integration requires an enterprise application registration in your Azure / Entra ID tenant. The tables below list the exact API permissions each application needs. For which tool uses which permission, see the [Microsoft permission reference](/connecting-integrations/microsoft-mcp/#permission-reference).

:::note
Your tenant administrator must grant these permissions before users can authenticate. Depending on the integration, permissions may be **delegated** (act on behalf of a signed-in user) or **application** (act as the service itself). Where an integration supports both, they are called out separately. Application permissions always require admin consent.
:::

## Microsoft Integrations

### Microsoft eDiscovery

#### Delegated Permissions

| API             | Permission               | Description                                         |
| --------------- | ------------------------ | --------------------------------------------------- |
| Microsoft Graph | User.Read                | Sign in and read user profile                       |
| Microsoft Graph | offline_access           | Maintain access to data you have given it access to |
| Microsoft Graph | eDiscovery.Read.All      | Read all eDiscovery objects                         |
| Microsoft Graph | eDiscovery.ReadWrite.All | Read and write all eDiscovery objects               |

#### Application Permissions

| API             | Permission               | Description                           |
| --------------- | ------------------------ | ------------------------------------- |
| Microsoft Graph | eDiscovery.Read.All      | Read all eDiscovery objects           |
| Microsoft Graph | eDiscovery.ReadWrite.All | Read and write all eDiscovery objects |

### Entra ID

#### Delegated Permissions

| API             | Permission                        | Description                                           |
| --------------- | --------------------------------- | ----------------------------------------------------- |
| Microsoft Graph | User.Read                         | Sign in and read user profile                         |
| Microsoft Graph | offline_access                    | Maintain access to data you have given it access to   |
| Microsoft Graph | AppRoleAssignment.ReadWrite.All   | Manage app permission grants and app role assignments |
| Microsoft Graph | AuditLog.Read.All                 | Read audit log data                                   |
| Microsoft Graph | Directory.Read.All                | Read directory data                                   |
| Microsoft Graph | DirectoryRecommendations.Read.All | Read Azure AD recommendations                         |
| Microsoft Graph | Group.Read.All                    | Read all groups                                       |
| Microsoft Graph | GroupMember.Read.All              | Read group memberships                                |
| Microsoft Graph | Policy.Read.All                   | Read your organization's policies                     |
| Microsoft Graph | Policy.Read.AuthenticationMethod  | Read authentication method policies                   |
| Microsoft Graph | Policy.Read.ConditionalAccess     | Read your organization's conditional access policies  |
| Microsoft Graph | Reports.Read.All                  | Read all usage reports                                |
| Microsoft Graph | RoleManagement.Read.Directory     | Read directory RBAC settings                          |
| Microsoft Graph | User.EnableDisableAccount.All     | Enable and disable user accounts                      |
| Microsoft Graph | User.Read.All                     | Read all users' full profiles                         |
| Microsoft Graph | User.ReadBasic.All                | Read all users' basic profiles                        |

#### Application Permissions

| API             | Permission                        | Description                                          |
| --------------- | --------------------------------- | ---------------------------------------------------- |
| Microsoft Graph | AuditLog.Read.All                 | Read all audit log data                              |
| Microsoft Graph | Directory.Read.All                | Read directory data                                  |
| Microsoft Graph | DirectoryRecommendations.Read.All | Read all Azure AD recommendations                    |
| Microsoft Graph | Group.Read.All                    | Read all groups                                      |
| Microsoft Graph | GroupMember.Read.All              | Read all group memberships                           |
| Microsoft Graph | Policy.Read.All                   | Read your organization's policies                    |
| Microsoft Graph | Policy.Read.AuthenticationMethod  | Read authentication method policies                  |
| Microsoft Graph | Policy.Read.ConditionalAccess     | Read your organization's conditional access policies |
| Microsoft Graph | Reports.Read.All                  | Read all usage reports                               |
| Microsoft Graph | RoleManagement.Read.Directory     | Read all directory RBAC settings                     |
| Microsoft Graph | User.EnableDisableAccount.All     | Enable and disable user accounts                     |
| Microsoft Graph | User.Read.All                     | Read all users' full profiles                        |

### Microsoft Defender

| API                         | Permission         | Description                                         |
| --------------------------- | ------------------ | --------------------------------------------------- |
| Microsoft Graph             | User.Read          | Sign in and read user profile                       |
| Microsoft Graph             | offline_access     | Maintain access to data you have given it access to |
| WindowsDefenderATP          | AdvancedQuery.Read | Run advanced queries                                |
| WindowsDefenderATP          | Alert.Read         | Read alerts                                         |
| WindowsDefenderATP          | Alert.ReadWrite    | Read and write alerts                               |
| Microsoft Threat Protection | Incident.Read      | Read incidents                                      |
| Microsoft Threat Protection | Incident.ReadWrite | Read and write incidents                            |
| WindowsDefenderATP          | Machine.Isolate    | Isolate machine                                     |
| WindowsDefenderATP          | Machine.Read       | Read machine information                            |
| WindowsDefenderATP          | Machine.Scan       | Scan machine                                        |
| WindowsDefenderATP          | Ti.ReadWrite       | Read and write IOCs                                 |

### Kindo Teams MCP Server

| API             | Permission                       | Description                                         |
| --------------- | -------------------------------- | --------------------------------------------------- |
| Microsoft Graph | User.Read                        | Sign in and read user profile                       |
| Microsoft Graph | offline_access                   | Maintain access to data you have given it access to |
| Microsoft Graph | Channel.ReadBasic.All            | Read the names and descriptions of channels         |
| Microsoft Graph | ChannelMessage.Read.All          | Read user channel messages                          |
| Microsoft Graph | ChannelMessage.Send              | Send channel messages                               |
| Microsoft Graph | Chat.Create                      | Create chats                                        |
| Microsoft Graph | Chat.Read                        | Read user chat messages                             |
| Microsoft Graph | Chat.ReadBasic                   | Read names and members of user chat threads         |
| Microsoft Graph | ChatMessage.Send                 | Send user chat messages                             |
| Microsoft Graph | Files.Read.All                   | Read all files that user can access                 |
| Microsoft Graph | Files.ReadWrite.All              | Have full access to all files user can access       |
| Microsoft Graph | OnlineMeetings.Read              | Read user's online meetings                         |
| Microsoft Graph | OnlineMeetingTranscript.Read.All | Read all transcripts of online meetings.            |
| Microsoft Graph | Team.ReadBasic.All               | Read the names and descriptions of teams            |
| Microsoft Graph | User.ReadBasic.All               | Read all users' basic profiles                      |

### Purview Compliance

#### Delegated Permissions

| API             | Permission                       | Description                                                  |
| --------------- | -------------------------------- | ------------------------------------------------------------ |
| Microsoft Graph | User.Read                        | Sign in and read user profile                                |
| Microsoft Graph | offline_access                   | Maintain access to data you have given it access to          |
| Microsoft Graph | AuditLogsQuery.Read.All          | Read audit logs data from all services                       |
| Microsoft Graph | Content.Process.User             | Process content for data security, governance and compliance |
| Microsoft Graph | Files.ReadWrite.All              | Have full access to all files user can access                |
| Microsoft Graph | InformationProtectionPolicy.Read | Read user sensitivity labels and label policies.             |
| Microsoft Graph | ProtectionScopes.Compute.User    | Compute Purview policies for an individual user              |
| Microsoft Graph | SecurityAlert.Read.All           | Read all security alerts                                     |
| Microsoft Graph | SecurityAlert.ReadWrite.All      | Read and write to all security alerts                        |
| Microsoft Graph | SecurityIncident.Read.All        | Read incidents                                               |
| Microsoft Graph | SecurityIncident.ReadWrite.All   | Read and write to incidents                                  |
| Microsoft Graph | ThreatHunting.Read.All           | Run hunting queries                                          |

#### Application Permissions

| API             | Permission                           | Description                                                       |
| --------------- | ------------------------------------ | ----------------------------------------------------------------- |
| Microsoft Graph | AuditLogsQuery.Read.All              | Read audit logs data from all services                            |
| Microsoft Graph | Content.Process.User                 | Process content for data security, governance and compliance      |
| Microsoft Graph | Files.ReadWrite.All                  | Read and write files in all site collections                      |
| Microsoft Graph | InformationProtectionPolicy.Read.All | Read all published labels and label policies for an organization. |
| Microsoft Graph | ProtectionScopes.Compute.All         | Compute Purview policies at tenant scope                          |
| Microsoft Graph | SecurityAlert.Read.All               | Read all security alerts                                          |
| Microsoft Graph | SecurityAlert.ReadWrite.All          | Read and write to all security alerts                             |
| Microsoft Graph | SecurityIncident.Read.All            | Read all security incidents                                       |
| Microsoft Graph | SecurityIncident.ReadWrite.All       | Read and write to all security incidents                          |
| Microsoft Graph | ThreatHunting.Read.All               | Run hunting queries                                               |

### Purview MCP

| API               | Permission              | Description                                         |
| ----------------- | ----------------------- | --------------------------------------------------- |
| Microsoft Graph   | User.Read               | Sign in and read user profile                       |
| Microsoft Graph   | offline_access          | Maintain access to data you have given it access to |
| Microsoft Purview | Purview.DelegatedAccess | Purview Delegated API Access                        |

The signed-in user also needs a Purview collection role (Data Reader, Data Curator, Data Source Administrator, or Collection Admin depending on the tools used).

### Intune

#### Delegated Permissions

| API             | Permission                                              | Description                                                       |
| --------------- | ------------------------------------------------------- | ----------------------------------------------------------------- |
| Microsoft Graph | User.Read                                               | Sign in and read user profile                                     |
| Microsoft Graph | offline_access                                          | Maintain access to data you have given it access to               |
| Microsoft Graph | DeviceManagementApps.Read.All                           | Read Microsoft Intune apps                                        |
| Microsoft Graph | DeviceManagementConfiguration.Read.All                  | Read Microsoft Intune Device Configuration and Policies           |
| Microsoft Graph | DeviceManagementManagedDevices.PrivilegedOperations.All | Perform user-impacting remote actions on Microsoft Intune devices |
| Microsoft Graph | DeviceManagementManagedDevices.Read.All                 | Read Microsoft Intune devices                                     |

#### Application Permissions

| API             | Permission                                              | Description                                                       |
| --------------- | ------------------------------------------------------- | ----------------------------------------------------------------- |
| Microsoft Graph | DeviceManagementApps.Read.All                           | Read Microsoft Intune apps                                        |
| Microsoft Graph | DeviceManagementConfiguration.Read.All                  | Read Microsoft Intune device configuration and policies           |
| Microsoft Graph | DeviceManagementManagedDevices.PrivilegedOperations.All | Perform user-impacting remote actions on Microsoft Intune devices |
| Microsoft Graph | DeviceManagementManagedDevices.Read.All                 | Read Microsoft Intune devices                                     |

### Outlook Calendar

| API             | Permission            | Description                                         |
| --------------- | --------------------- | --------------------------------------------------- |
| Microsoft Graph | User.Read             | Sign in and read user profile                       |
| Microsoft Graph | offline_access        | Maintain access to data you have given it access to |
| Microsoft Graph | Calendars.Read        | Read user calendars                                 |
| Microsoft Graph | Calendars.Read.Shared | Read user and shared calendars                      |
| Microsoft Graph | Calendars.ReadBasic   | Read basic details of user calendars                |
| Microsoft Graph | Calendars.ReadWrite   | Have full access to user calendars                  |

### Outlook

| API             | Permission            | Description                                         |
| --------------- | --------------------- | --------------------------------------------------- |
| Microsoft Graph | User.Read             | Sign in and read user profile                       |
| Microsoft Graph | offline_access        | Maintain access to data you have given it access to |
| Microsoft Graph | Calendars.Read        | Read user calendars                                 |
| Microsoft Graph | Calendars.Read.Shared | Read user and shared calendars                      |
| Microsoft Graph | Calendars.ReadBasic   | Read basic details of user calendars                |
| Microsoft Graph | Calendars.ReadWrite   | Have full access to user calendars                  |
| Microsoft Graph | Contacts.Read         | Read user contacts                                  |
| Microsoft Graph | Mail.Read             | Read user mail                                      |
| Microsoft Graph | Mail.ReadBasic        | Read user basic mail                                |
| Microsoft Graph | Mail.Send             | Send mail as a user                                 |
| Microsoft Graph | People.Read           | Read users' relevant people lists                   |

### Entra ID Governance

| API             | Permission                                           | Description                                                                         |
| --------------- | ---------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Microsoft Graph | User.Read                                            | Sign in and read user profile                                                       |
| Microsoft Graph | offline_access                                       | Maintain access to data you have given it access to                                 |
| Microsoft Graph | AccessReview.Read.All                                | Read all access reviews that user can access                                        |
| Microsoft Graph | AccessReview.ReadWrite.All                           | Manage all access reviews that user can access                                      |
| Microsoft Graph | EntitlementManagement.Read.All                       | Read all entitlement management resources                                           |
| Microsoft Graph | EntitlementManagement.ReadWrite.All                  | Read and write entitlement management resources                                     |
| Microsoft Graph | LifecycleWorkflows-Reports.Read.All                  | Read all Lifecycle workflows reports                                                |
| Microsoft Graph | LifecycleWorkflows-Workflow.Activate                 | Run workflows on-demand in Lifecycle workflows                                      |
| Microsoft Graph | LifecycleWorkflows-Workflow.ReadBasic.All            | List all workflows in Lifecycle workflows                                           |
| Microsoft Graph | PrivilegedAssignmentSchedule.Read.AzureADGroup       | Read assignment schedules for access to Azure AD groups                             |
| Microsoft Graph | PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup  | Read, create, and delete assignment schedules for access to Azure AD groups         |
| Microsoft Graph | PrivilegedEligibilitySchedule.Read.AzureADGroup      | Read eligibility schedules for access to Azure AD groups                            |
| Microsoft Graph | PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup | Read, create, and delete eligibility schedules for access to Azure AD groups        |
| Microsoft Graph | RoleAssignmentSchedule.Read.Directory                | Read all active role assignments for your company's directory                       |
| Microsoft Graph | RoleAssignmentSchedule.ReadWrite.Directory           | Read, update, and delete all active role assignments for your company's directory   |
| Microsoft Graph | RoleEligibilitySchedule.Read.Directory               | Read all eligible role assignments for your company's directory                     |
| Microsoft Graph | RoleEligibilitySchedule.ReadWrite.Directory          | Read, update, and delete all eligible role assignments for your company's directory |
| Microsoft Graph | RoleManagement.Read.Directory                        | Read directory RBAC settings                                                        |

### Excel Online

| API             | Permission      | Description                                         |
| --------------- | --------------- | --------------------------------------------------- |
| Microsoft Graph | User.Read       | Sign in and read user profile                       |
| Microsoft Graph | offline_access  | Maintain access to data you have given it access to |
| Microsoft Graph | Files.Read      | Read user files                                     |
| Microsoft Graph | Files.ReadWrite | Have full access to user files                      |

### Graph Security MCP

#### Delegated Permissions

| API             | Permission                      | Description                                         |
| --------------- | ------------------------------- | --------------------------------------------------- |
| Microsoft Graph | User.Read                       | Sign in and read user profile                       |
| Microsoft Graph | offline_access                  | Maintain access to data you have given it access to |
| Microsoft Graph | IdentityRiskyUser.Read.All      | Read identity risky user information                |
| Microsoft Graph | IdentityRiskyUser.ReadWrite.All | Read and write risky user information               |
| Microsoft Graph | SecurityAlert.Read.All          | Read all security alerts                            |
| Microsoft Graph | SecurityAlert.ReadWrite.All     | Read and write to all security alerts               |
| Microsoft Graph | SecurityEvents.Read.All         | Read your organization's security events            |
| Microsoft Graph | SecurityIncident.Read.All       | Read incidents                                      |
| Microsoft Graph | SecurityIncident.ReadWrite.All  | Read and write to incidents                         |
| Microsoft Graph | ThreatHunting.Read.All          | Run hunting queries                                 |

#### Application Permissions

| API             | Permission                      | Description                               |
| --------------- | ------------------------------- | ----------------------------------------- |
| Microsoft Graph | IdentityRiskyUser.Read.All      | Read all identity risky user information  |
| Microsoft Graph | IdentityRiskyUser.ReadWrite.All | Read and write all risky user information |
| Microsoft Graph | SecurityAlert.Read.All          | Read all security alerts                  |
| Microsoft Graph | SecurityAlert.ReadWrite.All     | Read and write to all security alerts     |
| Microsoft Graph | SecurityEvents.Read.All         | Read your organization's security events  |
| Microsoft Graph | SecurityIncident.Read.All       | Read all security incidents               |
| Microsoft Graph | SecurityIncident.ReadWrite.All  | Read and write to all security incidents  |
| Microsoft Graph | ThreatHunting.Read.All          | Run hunting queries                       |

### OneDrive

| API             | Permission          | Description                                         |
| --------------- | ------------------- | --------------------------------------------------- |
| Microsoft Graph | User.Read           | Sign in and read user profile                       |
| Microsoft Graph | offline_access      | Maintain access to data you have given it access to |
| Microsoft Graph | Files.Read          | Read user files                                     |
| Microsoft Graph | Files.Read.All      | Read all files that user can access                 |
| Microsoft Graph | Files.ReadWrite.All | Have full access to all files user can access       |

### SharePoint Online

| API             | Permission          | Description                                         |
| --------------- | ------------------- | --------------------------------------------------- |
| Microsoft Graph | User.Read           | Sign in and read user profile                       |
| Microsoft Graph | offline_access      | Maintain access to data you have given it access to |
| Microsoft Graph | Files.Read          | Read user files                                     |
| Microsoft Graph | Files.ReadWrite     | Have full access to user files                      |
| Microsoft Graph | Sites.Read.All      | Read items in all site collections                  |
| Microsoft Graph | Sites.ReadWrite.All | Edit or delete items in all site collections        |

### Microsoft Azure

#### Delegated Permissions

| API                      | Permission         | Description                                                     |
| ------------------------ | ------------------ | --------------------------------------------------------------- |
| Microsoft Graph          | User.Read          | Sign in and read user profile                                   |
| Microsoft Graph          | offline_access     | Maintain access to data you have given it access to             |
| Azure Service Management | user_impersonation | Access Azure Service Management as organization users (preview) |

#### Application Permissions

None. Azure Resource Manager has no application permissions; access comes from the Azure RBAC role below.

The signed-in user (or, in application mode, the app itself) also needs the **Reader** Azure RBAC role on the subscription or management group. Application mode needs no API permissions.

### Microsoft Defender for Cloud

| API                      | Permission         | Description                                                     |
| ------------------------ | ------------------ | --------------------------------------------------------------- |
| Microsoft Graph          | User.Read          | Sign in and read user profile                                   |
| Microsoft Graph          | offline_access     | Maintain access to data you have given it access to             |
| Azure Service Management | user_impersonation | Access Azure Service Management as organization users (preview) |

The signed-in user also needs the **Security Reader** Azure RBAC role, or **Security Admin** to update alerts.

### Microsoft Sentinel (Management)

| API                      | Permission         | Description                                                     |
| ------------------------ | ------------------ | --------------------------------------------------------------- |
| Microsoft Graph          | User.Read          | Sign in and read user profile                                   |
| Microsoft Graph          | offline_access     | Maintain access to data you have given it access to             |
| Azure Service Management | user_impersonation | Access Azure Service Management as organization users (preview) |

The signed-in user also needs the **Microsoft Sentinel Reader** Azure RBAC role, or **Microsoft Sentinel Responder** to update incidents and create bookmarks.

---

## "Tool Action Access Controls"

Source: https://docs.kindo.ai/admin/rbac-tool-actions/

Kindo allows administrators to control exactly which integrations and tool actions are available to users and AI agents. These controls operate at two levels -- **organization-wide defaults** and **per-user-group overrides** -- giving you fine-grained governance over what AI can do on behalf of your users.

## Why Tool Action Access Control Matters

When AI agents act on behalf of users, they can read data, create records, send messages, and modify systems through connected integrations. Without access controls, any user with an integration connection could invoke any tool action that integration exposes.

Tool action access controls let administrators:

- **Restrict sensitive actions** -- Block specific tool actions (e.g., deleting records, sending emails) while allowing read-only operations
- **Scope access by team** -- Give the engineering group access to GitHub and Jira tools while limiting the marketing group to HubSpot and Slack
- **Enforce least privilege** -- Start with access disabled by default and explicitly enable only what each group needs
- **Maintain compliance** -- Ensure AI agents operate within the same access boundaries as the users they represent

## How It Works

Kindo uses a **hierarchical permission model** to determine whether a user can invoke a specific tool action:

1. **Organization defaults** set the baseline for all users
2. **User group overrides** refine access for specific teams
3. **Individual user policies** allow personal approval preferences in Kindo chats and agents

### Permission Evaluation Order

When a user (or an agent acting on their behalf) attempts to use a tool, Kindo evaluates permissions in this order:

1. **Is the integration enabled at the org level?** If the organization has disabled the integration entirely, access is denied for all users regardless of group settings.
2. **Is the specific tool enabled at the org level?** Organizations can disable individual tools within an enabled integration.
3. **Does the user's group grant access?** If org defaults deny access, a user group can explicitly grant it. If org defaults allow access, a user group can explicitly revoke it.
4. **Which approval policy applies?** In Kindo chats and agents, a personal tool policy can run accessible tools automatically, ask for approval, or block them; otherwise the organization default applies. External MCP ignores personal preferences and uses the [organization approval setting](#organization-approval-setting): only **Run automatically** permits execution. Its discovery endpoint checks that setting before contacting any tool server.

### Multiple Group Membership

When a user belongs to multiple groups, the most permissive rule applies -- if **any** group grants access to a tool, the user can use it.

**Example:**
- Organization has Jira access disabled by default
- User A belongs to the "Engineering" and "Analytics" groups
- Engineering group has Jira access enabled
- Analytics group does not have Jira access enabled
- **Result:** User A can use Jira tools because the Engineering group grants access

## Configuring Organization Defaults

Organization defaults define the baseline access policy for all users.

:::note
You must be an Administrator to configure these settings.
:::

:::tip
For maximum security, set both default access policies to **Off** and explicitly enable only the integrations and tools your organization needs. This follows the principle of least privilege.
:::

## Configuring User Group Access

User groups allow you to define different access policies for different teams.

### Creating and Managing User Groups

For instructions on creating user groups and managing members, see [User Groups](/admin/user-groups/#creating-a-user-group).

## Shared Integration Connections

In addition to controlling which tools are accessible, administrators can share specific integration connections with user groups. This allows team members to use a shared connection (e.g., a team Jira account) without each user needing to set up their own.

Shared connections appear in the **Shared Integrations** section of a user group's Integration & Tool Access tab. Administrators can add or remove shared connections from this panel.

## Organization Approval Setting

The organization also has a default tool approval setting, separate from integration
and tool access permissions. It supplies the default for Kindo chats and agents when
the user has no personal policy for a tool.

On the [external MCP API](/apis/mcp/scoping/), the organization setting applies
without personal overrides:

- **Run automatically** — Otherwise-authorized tools can be discovered and executed.
- **Ask before running** — Tools are hidden and calls are refused with
  `manual_approval_required`, because external MCP cannot obtain Kindo approval.
- **Block** — Tools are hidden and calls are refused.

The web app does not expose a control for this organization setting. Contact your
Kindo representative to review or change it. For a tool requiring approval, use
Kindo chat if manual approvals are enabled for your organization.

## User-Level Tool Policies

Individual users can configure personal tool approval preferences that apply across
their Kindo chats and agents. These preferences do not apply to external MCP clients;
configure tool selection and approval preferences in that client instead.

:::note
**Ask before running** is being rolled out gradually and appears only for organizations enrolled in the rollout. Contact your Kindo representative if you want it enabled for your organization.
:::

- **Run automatically** -- Tool calls execute automatically without confirmation
- **Ask before running** -- The model may still call tools, but their execution is paused until the user running the agent explicitly approves the call to be made. For each requested tool call, the user is shown the name of the tool being called and the inputs the Agent would call the tool with. When possible, the Agent will also provide rationale for calling the tool and an explanation of the tool inputs that were chosen. The user may also choose to reject a tool call, which prevents that particular invocation from happening. Approvals and rejections are captured in the audit log.
- **Block** -- Tool calls in Kindo chats and agents are blocked even if organization or group settings allow them

Users set these preferences from within a chat session by configuring tool approval
settings for each available tool. Changes apply across that user's Kindo chats and
agents, rather than only to the current chat. They do not grant access to tools
disabled by organization or user-group access controls.

## Built-In Tool Controls

Beyond integration-based tools, Kindo provides organization-level controls for built-in capabilities:

- **Sandbox Network Access** -- Controls whether code execution sandboxes can access external networks
- **Web Search** -- Controls whether AI agents can perform web searches

These are configured in the **Integrations & Tools** tab under **Settings > Organization**.

## Relationship to Other Governance Controls

Tool action access controls work alongside Kindo's other governance features:

| Control | Purpose |
|---------|---------|
| **Tool Action Access** | Which tools and actions are available to which users |
| **Model Access Controls** | Which AI models users can access ([Security Controls](/admin/security-controls/)) |
| **DLP Filters** | Scan and redact sensitive data in requests and responses ([Governance](/features/governance/)) |
| **Audit Logging** | Record all tool invocations and actions ([Security Controls](/admin/security-controls/#audit-log)) |

DLP filters can be configured at both the organization and user group level, and apply to model interactions independently of tool access controls. Audit logging captures all tool invocations regardless of how access was granted.

## Common Scenarios

### Scenario: Restrict AI to read-only operations

An organization wants AI agents to read data from integrations but not create, update, or delete records.

1. Set **Default Tool Access** to **Off** at the organization level.
2. For each integration, expand the tool list and enable only read-oriented tools (e.g., `list_issues`, `get_document`, `search_contacts`).
3. Leave write-oriented tools disabled (e.g., `create_issue`, `delete_record`, `send_message`).

### Scenario: Team-scoped integration access

Different departments need access to different integrations.

1. Set **Default Integration Config Access** to **Off** at the organization level.
2. Create user groups for each department: "Engineering", "Sales", "Support".
3. In the Engineering group, enable GitHub, Jira, and PagerDuty integrations.
4. In the Sales group, enable Salesforce and HubSpot integrations.
5. In the Support group, enable Zendesk and Slack integrations.
6. Users only see and can use the integrations enabled for their group(s).

### Scenario: Default-allow with targeted restrictions

An organization wants most tools available but needs to block a few sensitive actions.

1. Set **Default Tool Access** to **On** at the organization level.
2. Disable specific high-risk tools (e.g., `delete_repository`, `send_bulk_email`) at the organization level.
3. These tools are blocked for all users regardless of group membership.

## Verification

To confirm tool action access controls are working:

1. **Check as admin** -- Navigate to [**Settings > Organization > Integrations & Tools**](https://app.kindo.ai/?settings=integration-and-tool-access) and verify the expected integrations and tools show the correct enabled/disabled status.
2. **Check group settings** -- Open each user group and verify the **Integration & Tool Access** tab shows the intended overrides.
3. **Test as user** -- In a chat session, verify that only the expected tools appear when the AI agent lists available actions. Tools that are disabled should not appear.
4. **Review audit logs** -- Check [**Settings > Organization > Audit Log**](https://app.kindo.ai/?settings=audit-log) for tool invocation events to confirm that access controls are being enforced.

## Troubleshooting

### User cannot access a tool they should have access to

1. Verify the **integration** is enabled at the organization level. If the integration is off, no group-level override can grant access to its tools.
2. Verify the **specific tool** is enabled at the organization level or in the user's group.
3. Confirm the user is a **member of the correct group**. Check under [**Settings > User Groups**](https://app.kindo.ai/?settings=user-groups) > **[Group] > Members**.
4. For Kindo chats and agents, check whether the user has set a **personal Block policy**. For external MCP clients, check the [organization approval setting](#organization-approval-setting); personal tool policies do not apply there.
5. Verify the user has an active **integration connection**. The user (or a shared connection from their group) must be connected to the integration.

### User can access a tool they should not have access to

1. Check if the user belongs to **multiple groups**. Access is granted if any group allows it.
2. Verify the **organization default** is not set to allow. If `Default Tool Access` is On, tools are available unless explicitly disabled.
3. Review the specific tool's status in **all groups the user belongs to**.

---

## Integration Identity Isolation

Source: https://docs.kindo.ai/admin/integration-trust-domains/

Enterprise customers with sensitive teams -- legal, finance, compliance, security -- often need a hard guarantee that one team's integration identities are invisible and inaccessible to the rest of the organization. This page walks through the two isolation patterns Kindo supports, how agents behave when running against an isolated integration, and the current limitations.

If you are looking for the underlying mechanics (org-level toggles, group-level overrides, multiple-group rules), start with [Tool Action Access Controls](/admin/rbac-tool-actions/) and [User Groups](/admin/user-groups/). This page composes those primitives into a guide for the isolation use case.

## Who This Is For

You should read this page if you need to answer one or more of the following questions for a security or compliance review:

- "Can the Legal team's Jira identity be used by anyone outside the Legal team?"
- "If an admin creates an agent that uses a shared Salesforce connection, can a member of a different team unintentionally run it with the admin's credentials?"
- "When an org-wide agent invokes a tool, whose credentials are used -- the agent author's or the user running the agent?"
- "How do I prove to an external reviewer that team A cannot see team B's connected services?"

## Threat Model

Identity isolation in Kindo addresses three concrete risks:

| Risk                              | What it means                                                                                                | Where Kindo enforces it                                                                                                                                                                                         |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Discovery**                     | A user outside the trusted team sees that the integration is connected, or sees which tools it exposes.      | Org-level default-deny policy + per-group integration enablement ([Tool Action Access Controls](/admin/rbac-tool-actions/)).                                                                                    |
| **Direct use**                    | A user outside the trusted team invokes a tool from the integration directly (chat, agent, API).             | Same as above -- tools the user's groups have not enabled are filtered out of the user's tool list, and the runtime rejects calls to tools they have no entitlement for.                                        |
| **Indirect use via shared agent** | A user outside the trusted team runs a shared agent that was authored against the trusted team's connection. | Connection sharing scope (user-group-scoped only) + runtime Cerbos `USE_INTEGRATION_CONNECTION` check during tool assembly (only tools backed by an authorized connection are registered for the conversation). |

The patterns below are designed so that all three risks are closed simultaneously when configured correctly.

## Isolation Approaches

Kindo supports two complementary isolation patterns. Most enterprise deployments combine both.

### Approach 1: Group-Scoped Integration Access

Make the organization's default policy deny-by-default, then explicitly grant the integration to the user group that should have access. Members of other groups do not see the integration in their tool list, cannot create a connection to it, and cannot invoke its tools.

**Use this when** the integration itself should be invisible to everyone outside the trusted team -- for example, a legal-team Jira workspace whose existence should not be discoverable by engineering or sales.

**What users in the trusted group see:** The integration appears in their connection list and chat tool list. They can create their own connection (or use a shared connection -- see below) and invoke any enabled tool.

**What users outside the trusted group see:** Nothing. The integration is filtered out of the integration picker, the chat tool list, and the agent builder. Tool calls referencing it would be denied at runtime, but the user has no surface to attempt one from.

:::note
**Audit overlapping group memberships.** Permissions are additive across groups -- if a user belongs to the trusted group **and** to any other group that also enables this integration, they will see and use it from either path ([User Groups -- Access Control Rules](/admin/user-groups/#access-control-rules)). For isolation to hold, enable the integration only in the trusted group, and review the memberships of users who appear in the trusted group to make sure they aren't picking up access through a broader group.
:::

:::caution
Do not set the integration itself to **Off** in the org-level Integration & Tool Access table as a way to scope access. The org-level integration toggle is a **ceiling** -- when an integration is **Off** at the organization level, no user group can re-enable it for its members ([User Groups -- Integration Access](/admin/user-groups/#integration-access)). Isolation must be configured through the default-deny policy plus per-group enablement, not through an org-level **Off**.
:::

### Approach 2: Individual Connections with Downstream Permissions

Allow every user to connect to the integration with their own credentials. The downstream service's permission model (e.g., Jira project permissions, Salesforce profile-based access) governs what each user can actually do. Kindo treats each connection as independent -- no user can use another user's connection unless it is explicitly shared.

**Use this when** the integration is enabled organization-wide but each user's view of it differs because of upstream permissions. For example, every employee has a Jira account, but the legal-team Jira project is restricted to legal at the Jira level. A non-legal user authenticating to Jira through Kindo simply cannot see the legal project -- isolation is enforced by Jira, not by Kindo.

**Trust assumption:** This pattern delegates isolation to the external service. If the external service's permission model is misconfigured, Kindo will faithfully reflect that misconfiguration. Approach 1 is stronger in this respect because Kindo enforces the boundary itself.

### Combining Both Approaches

For the strongest isolation, combine the two:

- Set the org default to deny, keep the specific integration set to **Active** at the org level, and enable it only for the trusted group (Approach 1) -- so non-trusted users never see it.
- Within the trusted group, require each user to connect with their own credentials (Approach 2) -- so even within the trusted group, downstream permissions further scope what each member can do.

This is the recommended posture for highly sensitive teams (legal, finance, security).

## Shared Integration Connections

Administrators can share an integration connection with one or more user groups. A shared connection appears to group members as a usable connection in chat and agents -- they do not need their own credentials to the external service.

**Sharing scope is per user group.** A connection can be shared with the Legal group without being visible or usable to any other group. The sharing relationship can be managed from the user group's **Integration & Tool Access** tab or from the integration connection's sharing options.

**Sharing does not bypass group-level integration access.** A user group must have the integration enabled at the group or organization level to use a shared connection. If the integration is disabled for the group, shared connections of that integration are also unavailable to the group's members.

**Connection sharing is the only way Kindo grants one user access to another user's credentials.** Without an explicit share, every user can only use connections they personally created.

:::caution
A shared connection means group members are acting under the admin's identity from the external service's perspective. The external service's audit trail will attribute actions to the admin's account, not to the user running the agent. Use individual connections (Approach 2) where attribution at the external service matters.
:::

## How Agents Interact with Isolated Integrations

A frequent enterprise question is whether running a shared agent silently broadens a user's effective credentials. Kindo's runtime is designed so that the answer is **no**: an agent invoking a tool uses a connection the _running user_ is authorized to use, not the author.

### Default Behavior (No Pinned Connection)

Your active connections are your personal defaults for chats and agents. You can
select several accounts for the same integration, such as two authorized accounts
for the same service, without switching your active connection between calls.

Give connections recognizable labels so you can tell the accounts apart, and
specify the intended account in your request when it matters. Each connection
also has a stable account handle; renaming its label does not change that handle.

When an agent invokes a tool and the author has not pinned a specific connection:

- Kindo uses the **running user's** active connections. Tools that support account selection let the assistant choose an account for each call from that set.
- If the running user has no usable connection for the integration, the tool call fails. The agent does not use the author's credentials.
- The tool call appears in the audit log under the running user and the connection used for that call.

External MCP clients use [one account per integration](/apis/mcp/scoping/#default-connection-resolution).

### Pinned Connection (Agent Authoring)

Chats, agents, and agent steps can be **pinned** to specific integration connections. This is useful when an admin builds an agent that should run against particular team connections, regardless of who triggers it. A pin can contain up to 25 connections for the same integration.

Pinning is **off by default at the organization level** and is governed by **Pinned Integration Connections Enabled** in the organization's security settings. Users can select multiple personal active connections without permission to pin. When pinning is disabled, newly assembled turns use the running user's active connections.

When pinning is enabled, Kindo enforces the following at runtime:

1. The agent author must have `USE` access to each connection at the time of pinning. Pinning a connection the author cannot use is rejected with a 403.
2. **The running user must independently have `USE` access to each pinned connection they use.** Same-organization membership is not sufficient -- the running user must own the connection directly or belong to a group it is explicitly shared with.
3. Unavailable connections are removed from the pinned set for that turn. Chats and agent runs can use the remaining authorized connections. If none remain for an integration, an active agent run fails; a follow-up chat cannot use that integration. Kindo does not silently replace a pin with an account outside the pinned set.
4. Changes to the pinning setting take effect when Kindo assembles a new turn.

Practically, pinning does not delegate credentials. Sharing a pinned agent with a teammate does not share the underlying credentials -- the teammate still needs an independent `USE` grant on the connection through ownership or a user-group share.

### Effect on Isolation

For a team using Approach 1 (group-scoped integration access):

- An org-wide agent invoking the team's integration will fail for any user outside the team, because the runtime resolves no authorized connection for that user.
- A pinned agent referencing the team's connection cannot be executed by users outside the team, even if the agent is shared with them.
- The team's integration is never indirectly exposed through a shared agent.

For a team using Approach 2 (individual connections):

- An org-wide agent invoking the integration uses the running user's own connection, so downstream permissions continue to apply per user.
- A pinned agent referencing one user's connection cannot be executed by another user unless the connection is shared via a user group.

## Verification Checklist

Before treating an isolation configuration as complete, walk through this checklist with at least one user inside the trusted group and one outside.

## Current Limitations

Kindo's isolation primitives address the core enterprise use cases, but a few rough edges remain. Document these explicitly when sharing this guide with external security reviewers.

| Limitation                                                                                     | What it means                                                                                                                                                                                                                                                                                     | Recommended workaround                                                                                                                                                                                                                                                                         |
| ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **No first-class "trust domain" object**                                                       | Isolation is composed from RBAC overrides, group membership, and connection sharing rather than being represented as a single named boundary in the UI. There is no single screen labeled "Legal team trust domain" that shows the full isolation posture at a glance.                            | Use a consistent naming convention for trusted groups (e.g., `Trust: Legal`, `Trust: Finance`) and document the configuration in your security review. The Verification Checklist above is the canonical way to confirm posture.                                                               |
| **Per-user delegated OAuth is not a first-class connection mode**                              | Some integrations require each user to connect individually (the default behavior) while others can be served by a shared admin connection. There is not yet a per-integration toggle that forces delegated auth and rejects shared service-account connections.                                  | For integrations where individual identity is required, instruct admins not to share their connection with any user group. Sharing requires an explicit administrator action, so the absence of shared connections is auditable from the **Integration & Tool Access** tab of each user group. |
| **Admin `manage` vs. `use` distinction for connections is finer-grained than the UI surfaces** | An administrator who can administer connections (delete, reconfigure) is not necessarily authorized to invoke tools against them, and vice versa. The backend enforces this split, but admin-facing surfaces do not always make the difference visible.                                           | Treat "admin" as the strongest available control, but verify with the audit log when investigating sensitive tool calls. Inspect the Raw Data payload of tool-invocation events for the connection metadata, not just the acting user.                                                         |
| **Connection sharing scope is per-user-group, not per-tool**                                   | When an admin shares a connection with a user group, every group member who can use the integration can use the shared connection on every tool action that integration exposes (subject to group-level tool overrides). There is no way to share a connection only for a subset of tool actions. | Use group-level tool action overrides (see [Tool Action Access Controls](/admin/rbac-tool-actions/)) to restrict the tool surface available to the group as a whole, which implicitly restricts what the shared connection can do.                                                             |

## Relationship to Other Governance Controls

| Control                                                                                 | Role in isolation                                                                                                                                                                     |
| --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Tool Action Access Controls](/admin/rbac-tool-actions/)                                | Org-level enable/disable, per-group overrides, per-tool granularity. The mechanics behind Approach 1.                                                                                 |
| [User Groups](/admin/user-groups/)                                                      | The membership boundary that scoping is applied against. Also governs feature permissions (Ask Mode, Agent Creation, etc.) that further constrain what isolated-group members can do. |
| [Security Controls -- Integration Access](/admin/security-controls/#integration-access) | The organization-level integration toggle that serves as the baseline.                                                                                                                |
| [Security Controls -- Audit Log](/admin/security-controls/#audit-log)                   | Records every tool invocation under the running user. The event's Raw Data payload carries connection metadata, providing the audit trail required by compliance reviewers.           |
| [Governance and Controls](/features/governance/)                                        | The framework overview that places these primitives in context.                                                                                                                       |

## Next Steps

- Walk through the [Verification Checklist](#verification-checklist) for each sensitive team in your organization.
- If you need finer-grained per-tool restrictions for an isolated group, see [Tool Action Access Controls](/admin/rbac-tool-actions/).

---

## Frequently Asked Questions

Source: https://docs.kindo.ai/admin/faq/

## What is Kindo?

Kindo is an AI-native automation platform for enterprise technical operations, including SecOps, DevOps, and ITOps teams. It uses intelligent AI agents and a domain-tuned LLM to automate operational workflows end-to-end. Kindo is model-agnostic and compatible with 26+ LLMs. Everything available in the UI is also accessible through a public API.

## How is Kindo different from chatbot platforms?

Kindo is a full agentic automation platform. Unlike chatbot tools that only provide an AI assistant for answering questions, Kindo agents autonomously make decisions and take actions in your systems. They orchestrate multi-step workflows across your tech stack with appropriate approvals, rather than simply alerting a human.

## What is an AI-native agent?

An AI-native agent in Kindo is an intelligent software assistant that understands natural language, reasons through tasks, and performs actions on your behalf. These agents encapsulate operational runbooks and playbooks. They can read human-written instructions and translate intent into programmatic actions like API calls, dynamically adapting to results at each step.

## What is DeepHat?

DeepHat is Kindo's proprietary LLM tailored for DevSecOps, SecOps, and infrastructure tasks. Trained on real-world IT incidents, cybersecurity scenarios, code logs, and CLI syntax, it excels at reading configurations, demonstrating exploits, and explaining root causes. It is designed for adversary simulation and red teaming.

## Can Kindo run without internet access?

Yes. Kindo supports fully on-premises deployment with no internet connection required. All data, models, and operations stay behind your firewall. AI models like DeepHat can run locally on your GPU infrastructure.

## What is MCP and how does Kindo use it?

The Model Context Protocol (MCP) is an open standard that allows AI agents to connect with external tools using a uniform JSON message format. Kindo uses MCP to integrate with virtually any system -- source control, cloud services, ticketing systems, SIEMs, databases, and more -- through a consistent interface.

## How does Kindo secure MCP connections?

Kindo acts as a governance layer between AI and your tools:

- **Data Loss Prevention (DLP)** -- Scans all data passing through for sensitive information and automatically redacts disallowed content.
- **No Credential Exposure** -- The LLM never sees raw credentials. Secrets are injected at execution time without revealing them to the model.
- **RBAC** -- Administrators define exactly which actions agents can perform on which systems.
- **Whitelisted Integrations** -- Only approved, trusted MCP connections are allowed.
- **Audit Logging** -- Every agent action and tool access is logged for review.

## What tasks can Kindo agents perform?

- **Vulnerability Management** -- Scan for CVEs, apply patches, trigger container rebuilds
- **IAM Enforcement** -- Audit roles and permissions, flag or auto-correct overly broad access
- **Incident Response** -- Triage alerts, gather logs, correlate root causes, contain issues
- **Infrastructure Automation** -- Rotate certificates, manage configurations, execute playbooks
- **Ticketing and Orchestration** -- Escalate tickets, create issues, orchestrate cross-tool workflows
- **Compliance Auditing** -- Check configurations against benchmarks, gather audit evidence

## Do I need to rewrite my runbooks?

No. Kindo augments your existing runbooks and playbooks. You can feed human-written procedures to an agent as instructions, and it will follow them. Kindo agents can also execute existing scripts and tools via integrations.

## How does human-in-the-loop work?

You can configure approval checkpoints where agents must pause and request human sign-off before taking certain actions. Operators review proposed actions and approve or deny with a single click. Escalation paths and full audit trails are built in.

## What models can I run?

Kindo is model-agnostic. It includes DeepHat and supports models from OpenAI (GPT-4), Anthropic (Claude), Google (Gemini), Meta (Llama), and more. You can use different models for different tasks within the same platform. All models operate under Kindo's security framework with DLP and audit logging.

## Can I run Kindo on premises?

Yes. Kindo offers fully on-premises deployment via Kubernetes Helm charts. You maintain full control over all data, models, and operations. The on-prem version includes all features -- the agent framework, DeepHat, integrations, and everything else.

## What security measures are built in?

- **RBAC** -- Role-based access for users and agents
- **DLP** -- Real-time monitoring and redaction of sensitive data
- **Audit Logging** -- Comprehensive trails of all actions and decisions
- **Encryption** -- Data encrypted at rest and in transit
- **Policy Engine** -- Configurable guardrails and action restrictions
- **Secrets Management** -- Secure credential storage with need-to-know access

## Does Kindo support compliance frameworks?

Kindo is SOC 2 Type 2 compliant and supports frameworks like ISO/IEC 27001, GDPR, and NIST CSF through its built-in security features. For FedRAMP requirements, Kindo can be deployed in approved cloud environments like AWS GovCloud under your own controls.

## How does Kindo integrate with my tools?

Kindo uses MCP and native integrations to connect with source repositories (GitHub, GitLab), CI/CD pipelines, cloud platforms (AWS, Azure, GCP), ITSM tools (Jira, ServiceNow), monitoring systems (Datadog, Splunk), and many more. Integrations are bi-directional and can be chained within a single workflow.

## What is a secure sandbox?

A secure sandbox is an isolated VM created for every agent conversation. Agents use sandboxes to run shell commands, execute Python scripts, download and transform data, and create documents. Sandboxes are hardened, never contain credentials, and are destroyed after inactivity.

---

## Cross App Access

Source: https://docs.kindo.ai/admin/cross-app-access/

:::note[Beta]
Cross App Access is in beta and is enabled per organization. To request access, contact your Kindo account team.
:::

Cross App Access (XAA) lets an AI agent your users have approved in Okta call Kindo's MCP gateway (`/v1/mcp`) on their behalf, without ever handling a Kindo API key. Okta issues a short-lived, user-bound token (an ID-JAG) that the approved app redeems directly with Kindo for a Kindo access token scoped to `kindo.mcp`. Kindo never sees the user's Okta credentials, and the app never handles a Kindo API key or the user's credentials. Each Kindo access token it redeems is short-lived — one hour, with no refresh token.

## Prerequisites

- The organization has a configured [SAML SSO](/admin/sso/) connection to Okta. Cross App Access resolves the calling user by matching the ID-JAG's SAML subject against that connection's accounts.
- Each user has signed in to Kindo through that SAML connection at least once. Cross App Access only matches users who already have a Kindo account linked to the connection.
- The Okta SAML app sends a persistent, email, or unspecified NameID format. Transient NameIDs aren't accepted. The ID-JAG's subject issuer must also be the SAML connection's IdP entity ID.
- An Okta administrator can create an OIN (Okta Integration Network) resource-app entry, or configure Cross App Access for an existing app, in the Okta admin console.
- Kindo Support or your account team has enabled Cross App Access for your organization.

## Values to give Okta

Configuring the Kindo side of an Okta resource-app entry needs five values:

| Value | Where it comes from |
| --- | --- |
| Issuer URL | `

### Approve a client

Cross App Access only accepts a redemption from a client an admin has explicitly approved. There are two kinds:

- **Pre-registered client** — choose the client's authentication method from
  the dropdown next to **Create client**, then select **Create client**:
  - **Secret in request body (client_secret_post)** — the default. Use this for VS Code's MCP OAuth client and most other clients.
  - **Secret in Authorization header (client_secret_basic)**.

  The client is created immediately with an automatic name (for example,
  "Kindo XAA client 9/25/2026") — there's no separate naming step. Kindo
  shows the client ID and secret exactly once. Copy the secret before closing
  the dialog — Kindo never displays it again.

- **CIMD (Client ID Metadata Document) client** — paste the client's own metadata-document URL (for example `https://client.example.com/.well-known/client-id-metadata.json`) under **Approve CIMD client**. Kindo fetches and validates the document the first time that client redeems an ID-JAG; until then it's listed by its URL alone, with no creation date.

The approved-clients list shows each client's name, type, and — for a pre-registered client — its authentication method.

## Statuses

The Cross App Access section shows one of these statuses:

| Status | Meaning |
| --- | --- |
| *(section hidden)* | Cross App Access isn't enabled for your organization. |
| *(prompt to set up SSO)* | Your organization has no configured SAML connection yet. |
| **Not configured** | SAML is configured, but no Cross App Access trust configuration has been saved yet. |
| **Needs attention** | A configuration exists, but at least one problem below needs fixing before it will admit a token. |
| **Ready** | Configured, enabled, and at least one client is approved — Okta-issued ID-JAGs can be redeemed. |

A **Needs attention** status lists the specific reason:

- **The bound SAML connection is missing or no longer configured.** — Reconnect or recreate the SAML connection under [Single Sign-On (SSO) Setup](/admin/sso/).
- **No clients are approved yet.** — Approve at least one client (see [Approve a client](#approve-a-client)).
- **Cross App Access is turned off.** — Toggle **Enabled** and save.

## Revoking and removing

- **Revoke a client** — select **Revoke** on a client's row. A pre-registered client's Kindo registration is deleted outright, so its next redemption attempt fails. A CIMD client loses its approval and is denied on its next redemption; if it had already self-registered a record on an earlier redemption, that record stays and is simply no longer approved. Either way, Kindo rechecks on every call, so the client's already-issued Kindo access tokens are also rejected on their next `/v1/mcp` call, even though they otherwise last up to an hour.
- **Remove Cross App Access** — select **Remove Cross App Access** to delete the entire configuration and every pre-registered client's Kindo registration. A CIMD client loses its approval instead — if it had already self-registered a record on an earlier redemption, that record stays but is no longer approved. Kindo access tokens already issued to those clients are also rejected on their next `/v1/mcp` call. This also frees the bound SAML connection to be deleted, if you no longer need it. This cannot be undone. If Cross App Access is later turned off for your organization while a configuration still exists, this remove option stays available so you can still remove the configuration (and then delete the SAML connection).

## Troubleshooting

- **xaa.dev's resource-app tester health check fails.** Point its health-check path at `/healthcheck` on your API origin — the API's existing probe endpoint. xaa.dev lets you change the health-check path from its default.
- **A pre-registered client fails with "client is not linked to resource(s)".** A pre-registered client's link to the Kindo MCP resource is recorded at client-creation time, using the API URL configured then. If your installation's API URL changes, every existing pre-registered client stops redeeming, and the Issuer URL and Resource values given to Okta (see [Values to give Okta](#values-to-give-okta)) need updating to match. Create a new pre-registered client (see [Approve a client](#approve-a-client)) rather than reusing the old one.
- **An ID-JAG redemption fails with "Assertion has expired."** An ID-JAG expires about five minutes after Okta issues it. Request a fresh one from Okta.
- **An ID-JAG redemption fails with "This assertion has already been redeemed."** An ID-JAG is single-use. Request a fresh one from Okta rather than retrying the same one.
- **An ID-JAG redemption fails with "No Kindo account matches this SAML subject."** The user has no Kindo account linked through the bound SAML connection. Have them sign in to Kindo with SAML SSO once, then request a fresh ID-JAG.
- **An ID-JAG redemption fails with "Assertion has no aud_tenant."** The Okta resource connection has no Audience/tenant ID. Enter your Kindo audience tenant ID (see [Values to give Okta](#values-to-give-okta)) in that field, then request a fresh ID-JAG.
- **An ID-JAG redemption fails with "Issuer is not trusted for this client."** Check that the Okta resource connection's Audience/tenant ID exactly matches the **Audience tenant ID** shown in Kindo's Cross App Access settings, that the **Okta org URL** in Kindo matches your Okta org, and that the client is approved (see [Approve a client](#approve-a-client)). Then request a fresh ID-JAG.
- **An ID-JAG redemption fails with "Transient NameID subjects are not accepted."** The Okta SAML app is sending a transient NameID. In the app's SAML settings, set the NameID format to persistent, email address, or unspecified, then request a fresh ID-JAG.
- **xaa.dev's playground mode is refused with "Assertion has no aud_tenant."** The playground doesn't send an `aud_tenant`, so test through your own Okta org instead.
- **xaa.dev can't reach the Kindo API, or the MCP call step is blocked by CORS.** xaa.dev redeems ID-JAGs server-side, so the Kindo API must be publicly reachable over HTTPS for that tester to use it. For the MCP call step specifically, use xaa.dev's Proxy Mode if a direct browser call is blocked by CORS.

## Cross App Access and Personal API Key Access

Cross App Access is not gated by the **Personal API Key Access** user-group entitlement (see [User Groups](/admin/user-groups/)) — that setting only affects a user's own Kindo API key. A user whose personal API key access is disabled can still be admitted through Cross App Access, provided their org's configuration is ready and an Okta admin has approved them for the resource app.

## See also

- [Single Sign-On (SSO) Setup](/admin/sso/) — the SAML connection Cross App Access resolves users against.
- [MCP API — Kindo extensions](/apis/mcp/kindo-extensions/) — the RFC 9728 discovery document Cross App Access clients use.
- [MCP API errors](/apis/mcp/errors/) — the Cross App Access token's `401`/`403` envelopes.

---

## Reference

Source: https://docs.kindo.ai/reference/

Authoritative reference for Kindo's terminology and operational best practices.

For the public REST APIs (authentication, Responses, Chat Completions, Messages, Chat Actions), see the [API getting-started page](/overview/getting-started/).

## Reference Material

---

## Glossary

Source: https://docs.kindo.ai/reference/glossary/

Quick reference for terms you will encounter across the Kindo documentation.

| Term | Definition |
|---|---|
| **Agent** | A Kindo-managed automation that executes a series of steps. Types include Chatbots, Workflow Agents, and Triggered Agents. |
| **Agent Memory** | [Memory Engine](/features/memory/) memory scoped to a single agent and shared across all runs and all users of that agent. Consent-gated: both the organization admin and the agent's author must opt the agent in. |
| **Agent Run** | The final output of an agent's last LLM Step. |
| **Agent Step** | An atomic operation within an agent: LLM Step, Action Step, or API Action Step. |
| **Auth Backend** | The component managing enterprise SSO and authentication. |
| **Budget** | A monthly spend warning amount, set on an agent or a department. When spend for the month reaches it, Kindo emails the organization's administrators. See [Budgets](/admin/budgets/). |
| **Capture** | The [Memory Engine](/features/memory/)'s process of saving conversation notes and explicitly requested facts into memory. |
| **Chat** | A collection of requests from a user to LLMs through the Kindo Terminal without an agent. |
| **Chatbot** | An agent that responds to users using information from an AI model and a knowledge base. |
| **Conversation Memory** | The historical collection of LLM responses within a chat or agent session — the context the model sees during that conversation. Distinct from the durable, cross-conversation [Memory Engine](/features/memory/). |
| **DeepHat** | Kindo's proprietary cybersecurity-focused LLM, optimized for DevSecOps tasks and adversary simulation. |
| **DLP (Data Loss Prevention)** | Filters that tokenize or redact sensitive data before it reaches AI models. |
| **Embeddings Model** | A model that converts content into numeric vectors for semantic search and retrieval. |
| **Environment** | (Self-Managed) The Kubernetes platform where Kindo's Helm Chart runs. |
| **File** | A file within the Kindo Platform -- uploaded by users, provided by integrations, or generated by AI. |
| **Integration** | An external system connected to Kindo for data ingestion and outbound actions (e.g., Jira, Slack). |
| **Kindo API** | Kindo's REST API surface. `api.kindo.ai` is the primary public API domain, providing unified auth, audit logging, and the full `/v1` surface including chat completions, responses, conversations, models, and agents. `llm.kindo.ai` is the legacy direct-to-LiteLLM path retained for backward compatibility; it supports only chat completions. |
| **Kindo SaaS** | The cloud-hosted version of Kindo, managed by the Kindo team. |
| **Kindo Terminal** | The primary user interface for making requests to AI models. |
| **LLM** | Large Language Model -- the AI model used in requests (e.g., GPT-4, Claude, DeepSeek R1). |
| **LLM Step** | An agent step that requests a response from an LLM. |
| **Audit Log** | A record of user, AI agent, and administrative actions within Kindo. Stored in the database and exportable as CSV. See [Security Controls](/admin/security-controls/#audit-log). |
| **MCP** | Model Context Protocol -- an open standard for connecting AI agents to external tools. |
| **Memory Engine** | The Kindo feature that captures durable facts from conversations and recalls them in later ones. Ships as two implementations: [User Memory and Agent Memory](/features/memory/). For a conversation's own in-session history, see Conversation Memory. |
| **Peripheries** | Third-party services Kindo depends on (Unleash, Qdrant, Presidio, etc.). |
| **Recall** | The [Memory Engine](/features/memory/)'s retrieval of stored memories relevant to the current conversation, provided to the model as context. |
| **Redis Streams** | The Redis data structure Kindo currently uses for real-time conversation streaming between backend services. Requires a non-sharded Redis deployment. See [Plan & Provision Infrastructure](/deploy/provision-infrastructure/#redis). |
| **Resource** | A structured data entity from an integration (Tickets, Users, Emails, Logs). |
| **Run** | An instance of interaction between a user and an LLM brokered by Kindo. |
| **Sandbox** | An isolated VM created per agent conversation for secure code execution. |
| **Secret** | A sensitive value (API key, token, etc.) stored in the Secrets Vault. |
| **Self-Managed Kindo (SMK)** | Kindo deployed in customer-controlled infrastructure via Kubernetes Helm Chart. |
| **Self-Managed Model** | An AI model hosted and managed by the customer rather than a cloud provider. |
| **Spend** | The cost of AI model usage, in US dollars, measured separately from the Kindo credit balance. [Budgets](/admin/budgets/#what-counts-as-spend) count spend on Kindo-provided models by agent and by department. |
| **State DB** | The backend relational database (PostgreSQL) holding Kindo's application state. |
| **Step Run** | The individual response of a single LLM Step within an agent. |
| **Sync Backend** | The component that syncs Kindo with external SaaS services (ticketing, storage, etc.). |
| **Target** | The output destination of an agent run (Terminal, ticketing system, API endpoint). |
| **Triggered Agent** | An agent that activates in response to an external event. The trigger can be an Integration Event (from a connected integration like Jira) or a Direct Webhook URL (a token-protected URL any system can `POST` to). |
| **Direct Webhook URL Trigger** | A workflow trigger exposed as a unique URL of the form `https://api.kindo.ai/webhook/agent/<workflowId>/<token>`. Any external system can `POST` JSON to it to invoke the agent, with the request body forwarded as the trigger payload. The agent runs under the workflow creator's identity. |
| **Run Condition (Natural Language)** | An optional free-form condition on a Direct Webhook URL trigger. An LLM evaluates it against the entire webhook payload to decide whether to invoke the agent. Outcomes are recorded in the **Agent Direct Webhook Condition Evaluated** audit event with the LLM's reasoning. |
| **Unleash** | Feature flag management platform used by Kindo for model configuration and feature toggles. |
| **User LLM** | An LLM that users or agents make requests to. Shown as "Models" in the Kindo UI. |
| **User Memory** | [Memory Engine](/features/memory/) memory scoped to an individual user within an organization. Private to that user and applied only in chats, never in agent conversations. |
| **Vector DB** | Vector database used for RAG and semantic search (Qdrant). |
| **Worker LLM** | An LLM used internally by Kindo for non-user operations. |
| **Workflow Agent** | An agent that conducts operations within systems of record, including API calls. |

---

## Prompt Engineering Quick Reference

Source: https://docs.kindo.ai/reference/prompt-engineering/

## Prompt Engineering Core Patterns

### 1. Role Specification

State the role clearly at the top of the prompt.

```plaintext
You are a senior security analyst reviewing endpoint and identity evidence for incident triage.
```

Why it helps: role framing sets expected depth, vocabulary, and decision style.

### 2. Output Contract

Specify exact output structure.

```plaintext
Output as a markdown table with columns:
Control ID | Coverage Level | Compliance Status | Rationale
```

Why it helps: strict schemas make output predictable and easier to review or automate.

### 3. Constraints and Decision Rules

Define boundaries and tie-break behavior.

```plaintext
If evidence suggests multiple categories, choose the highest-risk category and explain why.
Only include Critical and High severity findings in the remediation list.
```

Why it helps: constraints reduce drift and force deterministic prioritization.

### 4. Confidence Labels

Require confidence per finding.

```plaintext
Confidence levels:
- HIGH: clear direct evidence
- MEDIUM: likely but incomplete evidence
- LOW: ambiguous or insufficient evidence
```

Why it helps: confidence makes recommendations operationally actionable.

### 5. Iterative Refinement

Start simple, run, inspect, and refine.

```plaintext
Iteration 1: basic request
Iteration 2: role + schema
Iteration 3: categories + confidence + edge-case handling
```

Why it helps: real prompts improve through controlled iteration, not one-shot drafting.

## Knowledge Store Tips

- Attach only files relevant to the current task.
- Prefer structured formats (Markdown, CSV, JSON) when possible.
- Keep references current and remove stale material.
- Split large documents into focused sections to reduce retrieval noise.

:::tip
Structured inputs plus explicit prompt schemas produce the most stable outputs in workshop exercises.
:::

## Reusable Prompt Checklist

Use this checklist before running an agent:

- Role is explicit
- Objective is explicit
- Required categories or labels are explicit
- Output schema is explicit
- Confidence rules are explicit
- Edge-case handling is explicit
- Post-processing instructions are explicit (summary, priorities, next steps)

## Kindo Documentation Links

- [Kindo Documentation Home](https://docs.kindo.ai)
- [What is Kindo?](/start/what-is-kindo/)
- [Agents and Automation](/features/agents/)
- [Integrations Setup](/features/integrations/)
- [Best Practices](/best-practices/)
- [API Overview](/overview/getting-started/)

## Related Pages

- [Agent Construction Best Practices](/reference/agent-best-practices/)

---

## Agent Construction Best Practices

Source: https://docs.kindo.ai/reference/agent-best-practices/

## Build Principles

### One Job Per Step

If one step analyzes, prioritizes, formats, and ticket-files all at once, split it. Steps should each have one primary responsibility.

### Name Steps for Intent

Use explicit names such as `Fetch Open Vulnerabilities`, `Map Evidence to Controls`, or `Format Manager Summary`.

### Pick the Correct Step Type

- **LLM Step**: reasoning, categorization, summarization
- **Action Step**: deterministic reads/writes in integrations
- **API Action Step**: direct external HTTP interaction

### Test Incrementally

Build one step, run it, validate output, then add the next step.

### Start Simple

A reliable 2-step workflow is more valuable than an unstable 10-step workflow.

### Know When To Go Agentic

Use a single-step runbook with tool calling when the next action depends on what is discovered mid-run (for example, incident triage across multiple systems).

## Design Pattern Comparison

| Pattern | Best For | Tradeoff |
| --- | --- | --- |
| Procedural multi-step | Repeatable, fixed workflows | Less adaptive to unexpected findings |
| Agentic single-step | Dynamic investigations and branching decisions | Requires stronger prompt guardrails |

## Production Hardening Checklist

- Add explicit output schema and severity/confidence scales
- Require evidence attribution for every major claim
- Define escalation criteria (for example, CRITICAL implies immediate notification)
- Add failure handling paths (missing data, integration timeout)
- Log and review representative runs before full rollout

:::caution
Do not promote workshop outputs directly to production without adding validation, ownership, and monitoring.
:::

## Common Failure Modes and Fixes

| Failure Mode | Why It Happens | Practical Fix |
| --- | --- | --- |
| Overly broad or generic outputs | Prompt lacks structure and constraints | Add strict output schema and decision criteria |
| Inconsistent decisions across runs | Ambiguous thresholds | Encode explicit thresholds and tie-break rules |
| Missed evidence from integrated tools | Tool usage expectations are unclear | Require per-source evidence lines in final output |
| Unmaintainable workflows | Step intent is unclear | Rename and scope each step to one job |

## Recommended Follow-Up

- Revisit [Prompt Engineering Quick Reference](/reference/prompt-engineering/)
- Explore platform-level guidance in [Creating and Managing Agents](/features/creating-agents/)

---

## Tool Catalog

Source: https://docs.kindo.ai/reference/tool-catalog/

:::note[Beta]
The tool catalog is in beta. It is a point-in-time snapshot of the integration inventory, so an entry can differ from what your organization sees in product. Confirm availability in the agent's tool configuration, and tell your Kindo representative if something here looks wrong.
:::

A Kindo agent acts through tools. This catalog lists the tools an agent can be granted: the 123 integrations Kindo ships, the 2,368 tools they expose, and the built-in tools that need no integration at all.

Which of these an agent can actually call is set per agent and per user group. See [Tool Action Access Controls](/admin/rbac-tool-actions/) for how access is scoped, and [Integrations Setup](/features/integrations/) for how connections are configured.

## How tools are named

Once an integration is connected, each of its tools is exposed to the agent under a fully qualified name: the integration prefix, an underscore, then the tool name. The GitHub integration's `list_pull_requests` tool reaches the agent as `github_list_pull_requests`. The catalog pages list these fully qualified names.

An integration can be connected in more than one way. Microsoft Entra ID, for example, offers delegated OAuth, application credentials, and GCC High variants of each. Each variant is a separate connection with its own credentials, which is why 123 integrations yield 159 connectable entries.

The prefix comes from the connection, not from the integration, so each variant prefixes its tools with its own identifier. Jira Data Center's tools arrive as `jira-data-center-basic_*`, not `jira_*`. The catalog lists each integration's tools once, under its primary connection's prefix; if you connect through another variant, expect that variant's prefix on the same tool names.

Platform tools follow the same rule under the `platform` prefix, so `get_conversation` reaches the agent as `platform_get_conversation`. Most built-in tools carry no prefix at all: the agent sees `file_read` and `shell_exec`. The exception is `platform_search_docs`, which is a built-in despite the prefix — it is listed with the built-ins below, not with the platform tools. The `kindo_`-prefixed spellings below are the request-side `type` values used by the [Responses API](/apis/responses/kindo-extensions/), not the names an agent, transcript, or approval card shows.

## Integrations by category

## Built-in tools

These tools need no integration. Granting one in an agent's configuration is necessary but not sufficient: almost every built-in also depends on how your deployment is set up, so read the Requires column alongside the tool.

| Tool                             | Responses API type                     | Description                                                                             | Requires                                                                        |
| -------------------------------- | -------------------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| `library_list`                   | —                                      | List the files in the Kindo file library, with the content IDs the download tools take. | Nothing further                                                                 |
| `shell_exec`                     | `kindo_shell`                          | Run a shell command in the agent's sandbox.                                             | A configured sandbox provider                                                   |
| `file_read`                      | `kindo_file_read`                      | Read a file in the sandbox workspace.                                                   | A configured sandbox provider                                                   |
| `file_write`                     | `kindo_file_write`                     | Write a file in the sandbox workspace.                                                  | A configured sandbox provider                                                   |
| `file_list`                      | `kindo_file_list`                      | List the workspace's files.                                                             | A configured sandbox provider                                                   |
| `web_download`                   | `kindo_web_download`                   | Download a URL into the workspace.                                                      | A configured sandbox provider                                                   |
| `files_download_original`        | `kindo_files_download_original`        | Fetch an uploaded file in its original form.                                            | A configured sandbox provider                                                   |
| `files_download_as_text`         | `kindo_files_download_as_text`         | Fetch an uploaded file converted to text.                                               | A configured sandbox provider                                                   |
| `file_share_with_user`           | `kindo_file_share_with_user`           | Hand a workspace file back to the user.                                                 | A configured sandbox provider                                                   |
| `browser_control`                | `kindo_browser_control`                | Drive a headless browser session.                                                       | A sandbox provider, and browser automation enabled for the org                  |
| `browser_screenshot`             | `kindo_browser_screenshot`             | Capture the browser viewport.                                                           | A sandbox provider, and browser automation enabled for the org                  |
| `browser_list_network_requests`  | `kindo_browser_list_network_requests`  | List the requests the page made.                                                        | A sandbox provider, and browser automation enabled for the org                  |
| `browser_export_request_as_curl` | `kindo_browser_export_request_as_curl` | Export one captured request as curl.                                                    | A sandbox provider, and browser automation enabled for the org                  |
| `mint_upload_url`                | —                                      | Mint a short-lived signed upload URL for the integration tools that write files.        | A sandbox provider, and the preview enabled for your organization by Kindo      |
| `search`                         | `kindo_web_search`                     | Search the web.                                                                         | Web search enabled for the org                                                  |
| `knowledge_store_search`         | `kindo_knowledge_store_search`         | Search the org's knowledge store.                                                       | Knowledge Store enabled, with documents attached to the conversation            |
| `vpn_connect`                    | `kindo_vpn_connect`                    | Attach the sandbox to a customer network.                                               | Kindo-hosted deployments, with VPN tools enabled for the org                    |
| `vpn_disconnect`                 | `kindo_vpn_disconnect`                 | Detach the sandbox from that network.                                                   | Kindo-hosted deployments, with VPN tools enabled for the org                    |
| `dashboard_generate`             | `kindo_dashboard_generate`             | Build a dashboard from the run's data.                                                  | Experimental; Kindo-hosted orgs with Canvas dashboards enabled                  |
| `dashboard_update`               | `kindo_dashboard_update`               | Revise a dashboard already generated.                                                   | Experimental; Kindo-hosted orgs with Canvas dashboards enabled                  |
| `platform_search_docs`           | —                                      | Search Kindo's documentation for product and platform guidance.                         | Kindo docs search enabled for the deployment, and not a whitelabeled deployment |

## Platform tools

Tools an agent uses to read and drive Kindo itself, rather than an external system. Unlike the built-ins above, these arrive together when the Platform server is selected.

| Tool                                        | Description                                                                                                                    |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| `platform_get_conversation`                 | Read a conversation's messages and tool calls.                                                                                 |
| `platform_get_agent_run`                    | Read one agent run's status and output.                                                                                        |
| `platform_list_agents`                      | List the agents the caller can see.                                                                                            |
| `platform_view_agent_configuration`         | Read an agent's configuration summary, or use `section` and `cursor` for paged exact text and resource IDs.                    |
| `platform_list_agent_runs`                  | List an agent's runs.                                                                                                          |
| `platform_start_standalone_agent_run`       | Start an agent run.                                                                                                            |
| `platform_create_agent`                     | Create a prompt-based agent with optional model and initial tool servers, returning a saved configuration snapshot.            |
| `platform_edit_agent`                       | Change an agent's name, description, instructions, or model and return a saved configuration snapshot.                         |
| `platform_set_agent_tool_server`            | Enable or disable a whole tool server on an agent. Account connections and tool approval settings still govern execution.      |
| `platform_set_agent_skill`                  | Attach or detach an existing accessible skill by lineage ID. Requires Skills to be enabled.                                    |
| `platform_set_agent_knowledge_content`      | Attach or remove existing accessible knowledge content. Requires Knowledge Store to be enabled; attachment may start indexing. |
| `platform_list_agent_configuration_options` | List accessible model or tool server IDs, with pagination.                                                                     |
| `platform_list_departments`                 | List active departments and member counts, newest first, with pagination.                                                      |
| `platform_create_department`                | Create a department and return its ID.                                                                                         |
| `platform_rename_department`                | Rename an active department by ID.                                                                                             |
| `platform_archive_department`               | Archive a department and clear it from every current member.                                                                   |
| `platform_list_users`                       | List organization members with roles, departments, and bounded user-group summaries.                                           |
| `platform_get_user`                         | Look up one organization member by user ID or email.                                                                           |
| `platform_set_user_departments`             | Preview or apply up to 100 department assignments, reporting rejected rows separately.                                         |

Platform tools require Platform MCP to be enabled and configured for your
organization. Skill and knowledge attachment also require the `SKILLS` and
`KNOWLEDGE_STORE` feature flags respectively. Agent-level model selection requires
the Agent Builder Instructions beta (`AGENT_BUILDER_INSTRUCTIONS`); while it is
disabled, a model can be saved on the agent but does not override the request's
model at execution. Contact Kindo to request beta access.

Department and member-directory tools require organization-admin access.
Department tools have limited access on Kindo-hosted deployments and are not
available on self-managed deployments. Contact Kindo to request access; your
organization's plan must also include department management. Directory reads
remain available without those department-specific requirements. Discovery
omits directory and department tools when their requirements are not met.
Calls recheck current access, including when you use a previously discovered tool.

Use department and user IDs for assignments. Display values over 255 characters
end in `…`; group lists contain at most 50 entries and report truncation.
For bulk assignment, call with `dry_run: true` to preview, then `dry_run: false`
to apply. Omitting `dry_run` applies changes. The first assignment for a user
wins; invalid rows are rejected without blocking valid rows. Changes commit
by department, so a failure can leave part of a batch applied. If the result
is unavailable, inspect current departments and users before retrying.
Archiving clears all current members and cannot be reversed through these tools.

---

## Threat detection and response

Source: https://docs.kindo.ai/reference/tool-catalog/threat-detection-response/

:::note[Beta]
The tool catalog is in beta and is a point-in-time snapshot of the integration inventory, so an entry can differ from what your organization sees in product.
:::

Endpoint, network, and SIEM platforms an agent can query for detections, and act on to contain them. 32 integrations, 645 tools.

Tool names below are the fully qualified names an agent sees once the integration is connected. Where an integration offers more than one connection, the names shown use the primary connection's prefix; connecting through another variant prefixes its tools with that variant's own integration ID instead. See [Tool Catalog](/reference/tool-catalog/) for how tools are granted and named.

## Abnormal Security

19 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `abnormal-security_get_abuse_campaign` | Get details of a specific abuse campaign including reported messages and threat analysis | **required** `campaign_id` |
| `abnormal-security_get_case` | Get details of a specific account takeover case including severity, affected user, and timeline | **required** `case_id` |
| `abnormal-security_get_employee` | Get employee information including display name, job title, VIP status, and threat history | **required** `email_address` |
| `abnormal-security_get_employee_identity` | Get behavioral identity analysis (Genome data) for an employee from Abnormal's AI engine | **required** `email_address` |
| `abnormal-security_get_threat` | Get full details of a specific threat including messages, attack type, sender info, and remediation status | **required** `threat_id` |
| `abnormal-security_get_threat_action_status` | Check the status of an async threat remediation action | **required** `threat_id`, `action_id` |
| `abnormal-security_get_vendor_details` | Get vendor risk details, domain information, and risk score for a specific vendor domain | **required** `vendor_domain` |
| `abnormal-security_list_abuse_campaigns` | List reported phishing and abuse campaigns from the AI Security Mailbox | optional `filter_query`, `page_number`, `page_size` |
| `abnormal-security_list_audit_logs` | List portal audit logs with filtering by action type, category, and time range (max 90 days) | optional `action`, `category`, `filter_query`, `page_number`, `page_size` |
| `abnormal-security_list_cases` | List account takeover (ATO) cases with time range filtering. Requires Account Takeover license. | optional `filter_query`, `page_number`, `page_size` |
| `abnormal-security_list_detection_reports` | List Detection 360 misclassification reports (missed attacks and false positives) | optional `filter_query`, `page_number`, `page_size` |
| `abnormal-security_list_threats` | List detected email threats with filtering by time range, attack type, sender, recipient, and detection source | optional `attack_strategy`, `attack_type`, `attack_vector`, `filter_query`, `page_number`, `page_size`, `recipient`, `sender`, `source`, `subject` |
| `abnormal-security_list_vendor_cases` | List vendor-related compromise cases detected by Abnormal Security | optional `filter_query`, `page_number`, `page_size` |
| `abnormal-security_list_vendors` | List vendors monitored by Abnormal Security with time range filtering | optional `filter_query`, `page_number`, `page_size` |
| `abnormal-security_manage_case` | Update the status of an account takeover case (acknowledge, mark not actionable, etc.) | **required** `case_id`, `action` |
| `abnormal-security_remediate_messages` | Bulk remediate email messages found via search (delete or move to a target folder) | **required** `action`, `message_ids`<br />optional `remediation_reason`, `target_folder` |
| `abnormal-security_remediate_threat` | Remediate a threat (move messages to junk/quarantine) or unremediate (restore messages to inbox) | **required** `threat_id`, `action` |
| `abnormal-security_search_messages` | Search email messages by sender, recipient, subject, and time range across Abnormal and Quarantine sources | optional `end_time`, `filter_operator`, `page_number`, `page_size`, `recipient_email`, `sender_email`, `sender_name`, `start_time`, `subject` |
| `abnormal-security_submit_detection_report` | Submit a Detection 360 misclassification report for a missed attack or false positive | **required** `inquiry_type`, `reported_message_id`<br />optional `description` |

## Akamai Guardicore

16 tools. Available as 2 connections: Akamai Guardicore (Basic Auth) (Basic auth), Akamai Guardicore (Refresh Token) (API key).

| Tool | Description | Arguments |
| --- | --- | --- |
| `akamai-guardicore_get_asset` | Search for a single asset by ID, IP address, or hostname. Provide one of: asset_id (starts with ':vm'), ip_address, or name. Returns the first match from a fuzzy search. | optional `asset_id`, `ip_address`, `name` |
| `akamai-guardicore_get_asset_by_id` | Get full details of a specific asset by its unique UUID (e.g., '33d2f2e8-6221-4c87-bae1-52ca509ffe91'). Returns complete asset data including IPs, agent details, labels, orchestration info, and metadata. | **required** `asset_id` |
| `akamai-guardicore_get_connection_trends` | Get aggregated network connection graph data grouped by label dimensions. Requires a saved map ID (use list_saved_maps to find one). Computes connection patterns between asset groups over a time range using the Reveal visibility graph. | **required** `saved_map_id`, `from_time`, `to_time`<br />optional `group_by` |
| `akamai-guardicore_get_incident` | Get detailed information about a specific security incident by ID. Returns full incident data including affected assets, events, tags, recommendations, severity, and policy violations. | **required** `incident_id` |
| `akamai-guardicore_get_label` | Get detailed information about a specific visibility label by its ID. Returns the label definition including key, value, criteria, and associated assets. | **required** `label_id` |
| `akamai-guardicore_get_label_group` | Get detailed information about a specific label group by its ID. | **required** `group_id` |
| `akamai-guardicore_get_network_connections` | Retrieve network connection data for visibility into traffic between assets. Filter by time range, source, and destination IP. Shows process-level communication details. | **required** `from_time`, `to_time`<br />optional `destination`, `limit`, `offset`, `source` |
| `akamai-guardicore_list_agents` | List installed Akamai Guardicore agents across the environment. Returns agent details including status, version, hostname, and associated asset information. | optional `agent_type`, `limit`, `offset`, `search` |
| `akamai-guardicore_list_assets` | Search and list assets (endpoints/VMs) in the Akamai Guardicore environment. Filter by IP address, hostname, or search string. Returns asset details including IPs, status, labels, and metadata. | optional `limit`, `offset`, `search` |
| `akamai-guardicore_list_incidents` | List security incidents within a time range. Filter by severity (Low/Medium/High), incident type, source, destination, or tag. Returns incident summaries with affected assets, timing, and severity. | **required** `from_time`, `to_time`<br />optional `destination`, `incident_type`, `limit`, `offset`, `severity`, `source`, `tag` |
| `akamai-guardicore_list_label_groups` | List all label groups used for organizing labels into higher-level groupings. Label groups define segmentation boundaries and policy scopes. | optional `limit`, `offset` |
| `akamai-guardicore_list_labels` | List all visibility labels used for organizing assets into logical groupings such as geographical areas, business units, applications, and roles. | optional `limit`, `offset` |
| `akamai-guardicore_list_policy_rules` | List segmentation policy rules in the Akamai Guardicore environment. Filter by asset ID to see rules affecting a specific asset. Returns rule definitions including source/destination criteria, actions, and associated labels. | optional `asset_id`, `limit`, `offset`, `search` |
| `akamai-guardicore_list_projects` | List segmentation projects in the Akamai Guardicore environment. Projects organize segmentation policies and rules into logical groupings. | optional `limit`, `offset` |
| `akamai-guardicore_list_saved_maps` | List saved network visibility maps from the Reveal section. Excludes futile and incident-type maps. Returns map definitions including name, filters, time ranges, and layout configurations. | optional `limit`, `offset` |
| `akamai-guardicore_manage_label` | Add a label to assets or delete an existing label. Use action='add' with asset_ids to assign a label to specific assets, or action='delete' to permanently remove a label definition (affecting all assets). | **required** `action`, `label_key`, `label_value`<br />optional `asset_ids` |

## AWS GuardDuty

53 tools. Credentials are supplied in the connection settings.

| Tool | Description | Arguments |
| --- | --- | --- |
| `aws-guardduty_accept_administrator_invitation` | Accept a GuardDuty administrator invitation from a member account. Requires the detector ID, administrator account ID, and invitation ID. | **required** `detector_id`, `administrator_id`, `invitation_id` |
| `aws-guardduty_archive_findings` | Archive AWS GuardDuty findings to suppress them from the active findings list. Archived findings are retained and can be retrieved with archived=true filter, but are hidden from the default view. | **required** `detector_id`, `finding_ids` |
| `aws-guardduty_create_filter` | Create a new finding filter for a GuardDuty detector. Filters can auto-archive findings matching specific criteria (e.g., low severity, specific finding types, or certain resource types). | **required** `detector_id`, `name`, `finding_criteria`<br />optional `action`, `description`, `rank` |
| `aws-guardduty_create_members` | Add AWS accounts as GuardDuty member accounts. Provide account IDs and emails. After creating members, you must invite them and they must accept. | **required** `detector_id`, `account_details` |
| `aws-guardduty_create_sample_findings` | Generate sample AWS GuardDuty findings for testing and validation purposes. Sample findings simulate real GuardDuty findings and can be used to test alerting pipelines, verify integrations, and explore finding formats. | **required** `detector_id`<br />optional `finding_types` |
| `aws-guardduty_decline_invitations` | Decline GuardDuty membership invitations from administrator accounts. Provide the account IDs of the administrators whose invitations to decline. | **required** `account_ids` |
| `aws-guardduty_delete_detector` | Delete a GuardDuty detector. WARNING: This stops ALL GuardDuty monitoring in this region and deletes all findings. This action is irreversible. | **required** `detector_id` |
| `aws-guardduty_delete_filter` | Delete a GuardDuty finding filter by name. Findings previously suppressed by this filter will no longer be auto-archived. | **required** `detector_id`, `filter_name` |
| `aws-guardduty_delete_invitations` | Delete GuardDuty membership invitations. Removes the invitation records for the specified administrator accounts. | **required** `account_ids` |
| `aws-guardduty_delete_ip_set` | Delete a GuardDuty IP set. The trusted IP list will no longer suppress findings for those IPs. | **required** `detector_id`, `ip_set_id` |
| `aws-guardduty_delete_malware_protection_plan` | Delete a GuardDuty malware protection plan. S3 objects will no longer be scanned for malware under this plan. | **required** `malware_protection_plan_id` |
| `aws-guardduty_delete_members` | Remove AWS accounts from GuardDuty membership. The accounts will no longer be monitored by the administrator. | **required** `detector_id`, `account_ids` |
| `aws-guardduty_delete_publishing_destination` | Delete a GuardDuty publishing destination. Findings will no longer be exported to this destination. | **required** `detector_id`, `destination_id` |
| `aws-guardduty_delete_threat_intel_set` | Delete a GuardDuty threat intelligence set. The threat intel data will no longer be used for detection. | **required** `detector_id`, `threat_intel_set_id` |
| `aws-guardduty_describe_malware_scans` | Describe GuardDuty malware scan results with optional filtering. Returns scan details including status, resource scanned, threats found, scan start/end times, and trigger type. Useful for malware incident response. | **required** `detector_id`<br />optional `filter_criteria`, `max_results`, `next_token`, `sort_criteria` |
| `aws-guardduty_describe_publishing_destination` | Get details for a specific GuardDuty publishing destination, including its type (S3), status, destination ARN, KMS key ARN, and publishing failure information if applicable. | **required** `detector_id`, `destination_id` |
| `aws-guardduty_disassociate_members` | Disassociate member accounts from the GuardDuty administrator. The member accounts remain but are no longer actively monitored. | **required** `detector_id`, `account_ids` |
| `aws-guardduty_get_administrator_account` | Get the GuardDuty administrator account for a member detector. In multi-account setups, returns the administrator account ID, invitation ID, and relationship status. | **required** `detector_id` |
| `aws-guardduty_get_coverage_statistics` | Get aggregated GuardDuty coverage statistics showing resource counts by coverage status and resource type. Provides a quick overview of monitoring coverage without listing individual resources. | **required** `detector_id`, `statistics_type`<br />optional `filter_criteria` |
| `aws-guardduty_get_detector` | Get configuration details for a specific AWS GuardDuty detector, including its status (ENABLED/DISABLED), data sources configuration (CloudTrail, DNS logs, VPC Flow Logs, S3, EKS, Malware Protection), finding publishing frequency, and… | **required** `detector_id` |
| `aws-guardduty_get_filter` | Get details for a specific GuardDuty finding filter, including its name, action (NOOP or ARCHIVE), description, rank, and finding criteria. Filters define rules for auto-archiving or suppressing findings. | **required** `detector_id`, `filter_name` |
| `aws-guardduty_get_findings` | Retrieve comprehensive details for specific AWS GuardDuty findings by ID. | **required** `detector_id`, `finding_ids` |
| `aws-guardduty_get_findings_statistics` | Get aggregated statistics about AWS GuardDuty findings, counting findings by severity level (LOW, MEDIUM, HIGH, CRITICAL). Useful for dashboards and getting a quick overview of the security posture without fetching all findings. | **required** `detector_id`<br />optional `finding_criteria` |
| `aws-guardduty_get_invitations_count` | Get the count of pending GuardDuty membership invitations for the current account. | — |
| `aws-guardduty_get_ip_set` | Get details for a specific AWS GuardDuty IP set, including its name, format (TXT, STIX, etc.), S3 location, and activation status. IP sets contain trusted IP addresses that suppress findings. | **required** `detector_id`, `ip_set_id` |
| `aws-guardduty_get_malware_protection_plan` | Get details for a specific GuardDuty malware protection plan, including protected resource configuration, actions on malware detection, and plan status. | **required** `malware_protection_plan_id` |
| `aws-guardduty_get_malware_scan` | Get details for a specific GuardDuty malware scan by scan ID, including status, resource scanned, timing, and scan results. | **required** `scan_id` |
| `aws-guardduty_get_malware_scan_settings` | Get the malware scan settings for a GuardDuty detector, including EBS snapshot preservation settings and scan resource inclusion/exclusion tags. Shows how malware protection is configured for the detector. | **required** `detector_id` |
| `aws-guardduty_get_members` | Get details for specific GuardDuty member accounts by AWS account ID. Returns member account information including email, relationship status, invitation timestamp, and detector ID. | **required** `detector_id`, `account_ids` |
| `aws-guardduty_get_remaining_free_trial_days` | Get the remaining free trial days for GuardDuty data sources. Shows how many free trial days remain for each feature/data source per account. Useful for cost planning. | **required** `detector_id`, `account_ids` |
| `aws-guardduty_get_threat_intel_set` | Get details for a specific AWS GuardDuty threat intelligence set, including its name, format, location (S3 URL), and activation status. Threat intel sets contain known malicious IP addresses used for detection. | **required** `detector_id`, `threat_intel_set_id` |
| `aws-guardduty_get_usage_statistics` | Get GuardDuty usage statistics for cost monitoring and capacity planning. Returns usage data grouped by account, data source, resource, or features. Useful for understanding GuardDuty costs and data volumes. | **required** `detector_id`, `usage_statistic_type`<br />optional `max_results`, `next_token`, `usage_criteria` |
| `aws-guardduty_invite_members` | Send GuardDuty membership invitations to AWS accounts. The accounts must first be added with create_members. Optionally include a custom message and disable email notifications. | **required** `detector_id`, `account_ids`<br />optional `disable_email_notification`, `message` |
| `aws-guardduty_list_coverage` | List GuardDuty coverage details showing which resources are being monitored and their coverage status. Helps identify gaps in monitoring across EC2, ECS, EKS clusters, and other AWS resources. | **required** `detector_id`<br />optional `filter_criteria`, `max_results`, `next_token`, `sort_criteria` |
| `aws-guardduty_list_detectors` | List all AWS GuardDuty detector IDs in the configured region. A detector is the GuardDuty service instance that monitors your AWS environment. Most accounts have one detector per region. | optional `max_results`, `next_token` |
| `aws-guardduty_list_filters` | List all finding filter names for a GuardDuty detector. Filters auto-archive or suppress findings matching specific criteria. Returns filter names to use with get_filter for details. | **required** `detector_id`<br />optional `max_results`, `next_token` |
| `aws-guardduty_list_findings` | List AWS GuardDuty finding IDs with optional filters by severity, finding type, resource type, and archived status. Returns paginated finding IDs — pass them to get_findings to retrieve full details. | **required** `detector_id`<br />optional `archived`, `finding_type`, `max_results`, `next_token`, `resource_type`, `severity_min`, `sort_by`, `sort_order` |
| `aws-guardduty_list_invitations` | List all GuardDuty membership invitations sent to the current account. Returns invitation details including sender account, status, and timestamp. | optional `max_results`, `next_token` |
| `aws-guardduty_list_ip_sets` | List all IP set IDs associated with a GuardDuty detector. IP sets are lists of trusted or known malicious IP addresses used by GuardDuty for detection. Returns IDs to use with get_ip_set for details. | **required** `detector_id`<br />optional `max_results`, `next_token` |
| `aws-guardduty_list_malware_protection_plans` | List all GuardDuty malware protection plans. Malware protection plans define which S3 buckets are scanned for malware when new objects are uploaded. | optional `next_token` |
| `aws-guardduty_list_malware_scans` | List GuardDuty malware scans across the account with optional filtering and sorting. This API is account-scoped and does not take detector_id. | optional `filter_criteria`, `max_results`, `next_token`, `sort_criteria` |
| `aws-guardduty_list_members` | List member accounts associated with a GuardDuty administrator detector. In multi-account setups, this shows all member accounts being monitored. Returns account details including relationship status. | **required** `detector_id`<br />optional `max_results`, `next_token`, `only_associated` |
| `aws-guardduty_list_publishing_destinations` | List publishing destinations configured for a GuardDuty detector. Publishing destinations are S3 buckets where GuardDuty exports findings. Returns destination IDs, types, and status. | **required** `detector_id`<br />optional `max_results`, `next_token` |
| `aws-guardduty_list_tags_for_resource` | List tags associated with a GuardDuty resource (detector, filter, IP set, threat intel set). Provide the resource ARN. Returns key-value tag pairs. | **required** `resource_arn` |
| `aws-guardduty_list_threat_intel_sets` | List all threat intelligence set IDs associated with a GuardDuty detector. Threat intel sets are custom lists of known malicious IP addresses that GuardDuty uses to generate findings. Returns IDs to use with get_threat_intel_set. | **required** `detector_id`<br />optional `max_results`, `next_token` |
| `aws-guardduty_start_monitoring_members` | Re-enable GuardDuty monitoring for member accounts that were previously stopped. Findings will resume being generated. | **required** `detector_id`, `account_ids` |
| `aws-guardduty_stop_monitoring_members` | Stop GuardDuty monitoring for specific member accounts. Findings will no longer be generated for these accounts. | **required** `detector_id`, `account_ids` |
| `aws-guardduty_tag_resource` | Add tags to a GuardDuty resource. Tags are key-value pairs used for resource organization, cost allocation, and access control. Provide the resource ARN and a dict of tag key-value pairs. | **required** `resource_arn`, `tags` |
| `aws-guardduty_unarchive_findings` | Unarchive previously archived AWS GuardDuty findings, restoring them to the active findings list. Use when a finding was incorrectly archived or requires further investigation. | **required** `detector_id`, `finding_ids` |
| `aws-guardduty_untag_resource` | Remove tags from a GuardDuty resource by tag key. Provide the resource ARN and a list of tag keys to remove. | **required** `resource_arn`, `tag_keys` |
| `aws-guardduty_update_detector` | Update a GuardDuty detector's configuration. Can enable/disable the detector or change finding publishing frequency. Disabling a detector stops GuardDuty monitoring in that region. | **required** `detector_id`<br />optional `enable`, `finding_publishing_frequency` |
| `aws-guardduty_update_filter` | Update an existing GuardDuty finding filter. You can change the action, description, rank, or finding criteria. Use this to adjust suppression rules as your security posture evolves. | **required** `detector_id`, `filter_name`<br />optional `action`, `description`, `finding_criteria`, `rank` |
| `aws-guardduty_update_findings_feedback` | Submit feedback on AWS GuardDuty findings to indicate whether they are USEFUL (true positives) or NOT_USEFUL (false positives). This feedback helps AWS improve GuardDuty's machine learning models. | **required** `detector_id`, `finding_ids`, `feedback`<br />optional `comments` |

## AWS Security

10 tools. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `aws-security_analyze_iam_access` | — | optional `cursor`, `include_inherited`, `limit`, `principal`, `resource` |
| `aws-security_apply_remediation` | — | **required** `resource`, `action`<br />optional `apply_immediately`, `certificate_arn`, `confirm`, `dry_run`, `enabled`, `port`, `rotation_lambda_arn`, `security_group_ids` |
| `aws-security_aws_api_request` | — | **required** `service`, `action`<br />optional `account`, `confirm`, `dry_run`, `max_items`, `parameters`, `query`, `region` |
| `aws-security_delete_resource` | — | **required** `resource`<br />optional `confirm`, `dry_run`, `final_snapshot_id`, `force_empty_bucket`, `recovery_window_days`, `skip_final_snapshot`, `url_config_only` |
| `aws-security_find_public_exposure` | — | optional `accounts`, `cursor`, `limit`, `regions`, `severity` |
| `aws-security_get_resource` | — | **required** `resource_id`<br />optional `include` |
| `aws-security_list_accounts` | — | — |
| `aws-security_list_resources` | — | optional `accounts`, `cursor`, `limit`, `public_only`, `regions`, `services` |
| `aws-security_modify_network_access` | — | **required** `resource`, `action`<br />optional `cidr`, `confirm`, `dry_run`, `ports`, `protocol` |
| `aws-security_set_policy` | — | **required** `resource`, `action`<br />optional `confirm`, `dry_run`, `policy`, `policy_arn`, `policy_name`, `statement_id` |

## Cisco Secure Network Analytics

13 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cisco-secure-network-analytics_create_host_group` | Create a new host group (tag) in Cisco SNA. Host groups organize IP address ranges for traffic analysis and alarm scoping. | **required** `name`, `parent_id`, `ranges`<br />optional `description`, `location`, `tenant_id` |
| `cisco-secure-network-analytics_get_alarm_associated_flows` | Retrieve the constituent network flows that triggered a multi-peer SNA alarm. Available on SNA 7.5.3 and later. Returns 404 with a version hint on older Managers. | **required** `alarm_id`<br />optional `max_records`, `tenant_id` |
| `cisco-secure-network-analytics_get_flow_query_results` | Fetch the results of a completed SNA flow query job. Use after ``search_flows`` returns TIMEOUT, or to re-fetch results for a job that previously completed. The job must be in COMPLETED state. | **required** `job_id`<br />optional `tenant_id` |
| `cisco-secure-network-analytics_get_flow_query_status` | Return the current status of an async SNA flow query job. Possible statuses: QUEUED, IN_PROGRESS, COMPLETED, FAILED. Use after ``search_flows`` returns a TIMEOUT response. | **required** `job_id`<br />optional `tenant_id` |
| `cisco-secure-network-analytics_list_flow_exporters` | List NetFlow/IPFIX exporters feeding this SNA Manager, including health status, exporter IP, and last-seen timestamp. Use this to answer 'is this network device sending flow data?' or to diagnose gaps in flow coverage. | optional `tenant_id` |
| `cisco-secure-network-analytics_list_host_groups` | List host groups (called 'tags' in the SNA REST API, 'host groups' in the UI) for a given scope. | optional `scope`, `shape`, `tenant_id` |
| `cisco-secure-network-analytics_list_security_event_types` | List all security event type templates available on this SNA Manager. | optional `tenant_id` |
| `cisco-secure-network-analytics_list_tenants` | List all tenants (also called domains) visible to the authenticated user on this Cisco Secure Network Analytics Manager. Most enterprise deployments have a single tenant. | optional `tenant_id` |
| `cisco-secure-network-analytics_render_security_event_details` | Substitute event-specific field values (baseline, tolerance, threshold, etc.) into a security event type template to produce a human-readable description of why the event fired. | **required** `template_id`, `fields`<br />optional `tenant_id` |
| `cisco-secure-network-analytics_search_flows` | Search network flows on Cisco SNA using an async query job. Starts a flow query, polls for completion (up to 90 s), and returns results. | **required** `start_time`, `end_time`<br />optional `application_id`, `host_group_id`, `record_limit`, `source_ip`, `target_ip`, `tenant_id` |
| `cisco-secure-network-analytics_search_security_events` | Search Cisco SNA security events (alarms) using an async query job. Starts the job, polls for completion (up to 90 s), and returns results. | **required** `start_time`, `end_time`<br />optional `alarm_category_id`, `host_ips`, `security_event_type_ids`, `tenant_id` |
| `cisco-secure-network-analytics_top_traffic_report` | Generate a top-N traffic report for a Cisco SNA tenant. Aggregates traffic across the specified dimension and returns the top results. | **required** `dimension`, `start_time`, `end_time`<br />optional `host_group_id`, `limit`, `tenant_id` |
| `cisco-secure-network-analytics_update_host_group` | Update an existing host group (tag) in Cisco SNA. **SNA's PUT is a full replace** — this tool fetches the current host group, merges your changes, and PUTs back, so you only need to specify what you want to change. | **required** `host_group_id`<br />optional `description`, `name`, `ranges`, `ranges_action`, `tenant_id` |

## Cofense Triage

17 tools. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cofense-triage_add_report_comment` | Add an analyst comment to a report. Comments create an auditable trail of investigation activities, findings, and decisions. Requires Triage Operator role or higher. | **required** `reportId`, `body`<br />optional `bodyFormat`, `tags` |
| `cofense-triage_categorize_report` | Categorize or re-categorize a phishing report. This is a critical operation that classifies the report and may trigger automated workflows (notifications, integrations, metrics). Requires Triage Operator role or higher. | **required** `reportId`, `categoryId`<br />optional `categorizationTags`, `outboundTemplateId` |
| `cofense-triage_download_attachment` | Download a specific attachment file from a report. Returns base64-encoded binary data with filename and content type. Use with caution - attachments may contain malware. Consider downloading in a sandboxed environment. | **required** `attachmentId` |
| `cofense-triage_download_attachment_payload` | Download the raw payload content (binary data as base64). This represents the actual file content shared across potentially multiple attachments with the same hash. | **required** `payloadId` |
| `cofense-triage_download_report_original` | Download the original email in RFC822 (.eml) format. Returns the complete email source including all headers, body, and MIME parts as base64-encoded data. Useful for forensic analysis or forwarding to external tools. | **required** `reportId` |
| `cofense-triage_download_report_preview` | Download a rendered preview image of the email (PNG or JPG format). Returns base64-encoded image data. Useful for quick visual triage without opening the original email. | **required** `reportId`<br />optional `format` |
| `cofense-triage_get_attachment_payload` | Get payload metadata including file hashes (MD5, SHA256), MIME type, and risk score. Useful for threat intelligence lookups without downloading the actual file. | **required** `payloadId` |
| `cofense-triage_get_category` | Get detailed information about a specific category by its ID, including name, description, color, score, and malicious flag. | **required** `categoryId` |
| `cofense-triage_get_report` | Get detailed information about a specific phishing report by its ID. Returns the full report resource including all attributes and relationship identifiers. | **required** `reportId` |
| `cofense-triage_get_report_with_context` | Get a comprehensive view of a report including all related context: URLs, domains, hostnames, email headers, attachments, payloads, comments, rules, threat indicators, cluster information, and categorization. | **required** `reportId`<br />optional `includeRelations` |
| `cofense-triage_list_categories` | List all available report categories in Triage. Categories classify reports as malicious (phishing, malware, spam) or benign (legitimate, training). Used to discover valid category IDs before categorizing reports. | optional `malicious`, `nameContains`, `page`, `pageSize` |
| `cofense-triage_list_headers_for_report` | List all RFC-822 email headers from a report (e.g., From, To, Subject, Received, Message-ID, X-headers). Returns key-value pairs useful for analyzing email routing, authentication (SPF/DKIM/DMARC), and identifying spoofing attempts. | **required** `reportId` |
| `cofense-triage_list_integration_results_for_report` | Aggregate all third-party security tool verdicts for URLs and files in a report. Returns integration submission results from tools like VirusTotal, sandboxes, URL reputation services, etc. | **required** `reportId`<br />optional `targetKinds` |
| `cofense-triage_list_iocs_for_report` | List all indicators of compromise (IOCs) extracted from a report. Returns URLs, domains, hostnames, and threat indicators in a consolidated response. | **required** `reportId` |
| `cofense-triage_list_report_attachments` | List all attachments from a report. Returns metadata including filename, size, content type, and linkage to attachment payload (hash information). Essential for identifying suspicious files. | **required** `reportId` |
| `cofense-triage_list_report_comments` | List all comments on a report. Comments contain analyst notes, investigation findings, and collaboration discussion. Supports pagination. | **required** `reportId`<br />optional `page`, `pageSize` |
| `cofense-triage_list_reports` | List and filter phishing reports from Cofense Triage. Supports pagination (max 200 per page), filtering by subject, sender, tags, date range, category, and priority. | optional `categoryId`, `fromAddress`, `matchPriority`, `page`, `pageSize`, `receivedAfter`, `receivedBefore`, `sort`, `subjectContains`, `tagsAny` |

## CrowdStrike Falcon

81 tools. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `crowdstrike-falcon_aggregate_alerts` | Get aggregate counts and analytics of alerts across all CrowdStrike Falconsecurity products. Provides powerful analytics for threat intelligence, trend analysis, and security metrics. | **required** `field`<br />optional `aggregation_type`, `date_ranges`, `filter_query`, `include_hidden`, `interval`, `name`, `size`, `sort` |
| `crowdstrike-falcon_block_identity_authentication` | Block authentication for one or more CrowdStrike Falcon Identity Protection identities by creating a real-time enforcement policy rule (action BLOCK) scoped to those source users. Enforced at the domain controller by the Falcon sensor. | **required** `rule_name`, `source_user_entity_ids`<br />optional `simulation_mode`, `trigger` |
| `crowdstrike-falcon_create_identity_protection_policy_rule` | Create a CrowdStrike Falcon Identity Protection policy rule. Defines a conditional access / risk response for identity activity. | **required** `name`, `action`, `trigger`<br />optional `activity`, `destination`, `enabled`, `simulation_mode`, `source_endpoint`, `source_user` |
| `crowdstrike-falcon_create_ioa_rule` | Create a new Custom IOA rule inside an existing rule group in CrowdStrike Falcon. | **required** `rulegroup_id`, `ruletype_id`, `name`, `pattern_severity`, `disposition_id`, `field_values`<br />optional `comment`, `description` |
| `crowdstrike-falcon_create_ioa_rule_group` | Create a new Custom IOA rule group in CrowdStrike Falcon. A rule group is a per-platform container that holds individual IOA rules. Create the group first, then add rules to it with create_ioa_rule. | **required** `name`, `platform`<br />optional `comment`, `description` |
| `crowdstrike-falcon_create_ioc` | Create a custom Indicator of Compromise (IOC) in CrowdStrike Falcon. Supports IP addresses, domains, and file hashes with configurable detection/prevention actions. | **required** `ioc_type`, `value`, `action`, `platforms`<br />optional `applied_globally`, `description`, `expiration`, `host_groups`, `severity`, `source`, `tags` |
| `crowdstrike-falcon_delete_identity_protection_policy_rules` | Delete one or more CrowdStrike Falcon Identity Protection policy rules by ID. This permanently removes the rules. Get rule IDs from list_identity_protection_policy_rules first. WARNING: This action is irreversible. | **required** `ids` |
| `crowdstrike-falcon_delete_ioc` | Delete one or more custom IOCs from CrowdStrike Falcon by their IDs. This permanently removes the indicators. Get IOC IDs from list_iocs first. WARNING: This action is irreversible. | **required** `ids` |
| `crowdstrike-falcon_disable_identity_account` | Disable an on-prem Active Directory account for a CrowdStrike Falcon Identity Protection entity, enforced through the Falcon sensor on the domain controller (no separate AD connector required). | **required** `entity_id` |
| `crowdstrike-falcon_find_shadow_admins` | List CrowdStrike Falcon Identity Protection entities that are members of the built-in Active Directory Administrator role (BuiltinAdministratorRole). Does NOT enumerate custom, delegated, or nested-group admin roles. | optional `after`, `limit` |
| `crowdstrike-falcon_find_stale_accounts` | Return Active-Directory-backed CrowdStrike Falcon Identity Protection USER entities with account/password age metadata (enabled state, last-update time, password last-change) so stale or dormant accounts can be identified. | optional `after`, `limit` |
| `crowdstrike-falcon_force_identity_password_reset` | Force a password reset for a CrowdStrike Falcon Identity Protection entity's on-prem AD account, enforced via the Falcon sensor on the domain controller. | **required** `entity_id` |
| `crowdstrike-falcon_get_alert_details` | Get comprehensive details for specific alerts across all CrowdStrike Falconsecurity products. Returns full context including process trees, MITRE ATT&CK mappings, IOCs, device information, and threat intelligence. | **required** `ids`<br />optional `include_hidden` |
| `crowdstrike-falcon_get_alerts_combined` | Retrieve all Alerts that match a particular FQL filter in a single API call using cursor-based pagination. Returns alerts and an 'after' token for the next page when more results are available. | optional `after`, `filter_query`, `limit`, `sort` |
| `crowdstrike-falcon_get_analysis_report` | Retrieve CrowdStrike Falcon Sandbox analysis reports by ID. Returns verdict, extracted IOCs, behavioral indicators, MITRE ATT&CK mappings, and process activity. Requires the falconx-sandbox:read API scope. | **required** `ids`<br />optional `summary` |
| `crowdstrike-falcon_get_cloud_security_policy_details` | Get detailed information for specific Cloud Security (CSPM) policy IDs, including the policy statement, remediation guidance, and current severity/enabled configuration. Get policy IDs from list_cloud_security_policies first. | **required** `ids` |
| `crowdstrike-falcon_get_content_update_policy_details` | Get detailed configuration for specific content update policy IDs, including the ring assignment settings (ring and delay hours) per content category. Get policy IDs from list_content_update_policies first. | **required** `ids` |
| `crowdstrike-falcon_get_device_control_policy_details` | Get detailed configuration for specific device control policy IDs, including the per-device-class enforcement actions and exceptions. Get policy IDs from list_device_control_policies first. | **required** `ids` |
| `crowdstrike-falcon_get_device_details` | Get detailed information for specific device IDs including hardware, OS, network, and policy information | **required** `ids` |
| `crowdstrike-falcon_get_device_login_history` | Get recent login history for devices including user sessions and authentication details | **required** `ids` |
| `crowdstrike-falcon_get_device_network_history` | Get network address history for devices including IP and MAC address changes | **required** `ids` |
| `crowdstrike-falcon_get_device_online_state` | Get the current online status for specific devices (online, offline, unknown) | **required** `ids` |
| `crowdstrike-falcon_get_environment_score` | Get an environment-wide security risk score and summary (supersedes CrowdScore) computed from alert aggregations. | optional `filter_query` |
| `crowdstrike-falcon_get_identity_auth_history` | Retrieve account details for a specific CrowdStrike Falcon Identity Protection identity, resolved by email or entity ID. | optional `email`, `entity_id`, `limit` |
| `crowdstrike-falcon_get_identity_protection_policy_rule_details` | Get detailed configuration for specific Identity Protection policy rule IDs, including the trigger, action, simulation mode, and source/destination/activity matching criteria. Get rule IDs from list_identity_protection_policy_rules first. | **required** `ids` |
| `crowdstrike-falcon_get_identity_risk_scores` | Return CrowdStrike Falcon Identity Protection USER entities ranked by identity risk score (highest first), with risk factors. Requires Identity Protection Entities READ and GraphQL WRITE scopes. | optional `after`, `limit`, `min_severity` |
| `crowdstrike-falcon_get_ioa_rule_details` | Get full details of one or more Custom IOA rules in CrowdStrike Falcon by their IDs, including field values, disposition, pattern severity, and version. Get rule IDs from list_ioa_rules first. | **required** `ids` |
| `crowdstrike-falcon_get_ioa_rule_group_details` | Get full details of one or more Custom IOA rule groups in CrowdStrike Falcon by their IDs, including the rules contained in each group and the group's version (needed for subsequent updates). | **required** `ids` |
| `crowdstrike-falcon_get_ioa_rule_type_details` | Get the full field definitions for one or more Custom IOA rule types in CrowdStrike Falcon. | **required** `ids` |
| `crowdstrike-falcon_get_it_automation_policy_details` | Get detailed configuration for specific IT Automation policy IDs, including execution toggles (script/Python/OS Query), timeouts, and CPU / memory / concurrency resource limits. Get policy IDs from list_it_automation_policies first. | **required** `ids` |
| `crowdstrike-falcon_get_policy_host_counts` | Get the applied, pending, and total assigned host counts for a single CrowdStrike Falcon policy. | **required** `policy_type`, `policy_id` |
| `crowdstrike-falcon_get_prevention_policy_details` | Get detailed information for specific prevention policy IDs. Retrieves comprehensive prevention policy details including settings, configurations, platform information, and policy metadata. | **required** `ids` |
| `crowdstrike-falcon_get_response_policy_details` | Get detailed configuration for specific Real Time Response policy IDs, including the per-capability settings (e.g. RealTimeResponse, RealTimeResponseAdmin, custom scripts, file uploads). Get policy IDs from list_response_policies first. | **required** `ids` |
| `crowdstrike-falcon_get_sensor_policy_details` | Get full configuration details for specific sensor update policy IDs. Returns the complete settings block including sensor build version, channel/variant assignments, uninstall protection, and the update scheduler. | **required** `ids` |
| `crowdstrike-falcon_get_submission_status` | Check the status of one or more CrowdStrike Falcon Sandbox submissions. Analysis typically completes within 15 minutes. Requires the falconx-sandbox:read API scope. | **required** `ids` |
| `crowdstrike-falcon_get_zero_trust_assessment` | Get CrowdStrike Falcon Zero Trust Assessment (ZTA) posture data for one or more hosts by agent ID (AID). Returns the 1-100 security posture score the Falcon sensor computes from sensor and OS configuration. | **required** `ids` |
| `crowdstrike-falcon_kill_identity_sessions` | Terminate active authentication sessions for a CrowdStrike Falcon Identity Protection entity, enforced via the Falcon sensor. | **required** `entity_id` |
| `crowdstrike-falcon_list_alerts` | Query CrowdStrike Falcon alerts across all security products using FQL filters. | optional `filter_query`, `include_hidden`, `limit`, `offset`, `q`, `sort` |
| `crowdstrike-falcon_list_cloud_ml_policies` | List CrowdStrike Falcon prevention policies along with their Cloud ML and Sensor ML machine-learning settings. | optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_list_cloud_security_policies` | List CrowdStrike Falcon Cloud Security (CSPM / Falcon Horizon) policy settings. | optional `cloud_platform`, `service` |
| `crowdstrike-falcon_list_content_update_policies` | List CrowdStrike Falcon content update policies using FQL filters. | optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_list_device_control_policies` | List CrowdStrike Falcon device control (USB) policies using FQL filters. Device control policies govern how USB mass-storage and other peripheral device classes are allowed, blocked, or made read-only on endpoints. | optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_list_falcon_container_policies` | List all CrowdStrike Falcon Container image assessment policies. | — |
| `crowdstrike-falcon_list_identity_protection_policy_rules` | List CrowdStrike Falcon Identity Protection policy rules. | optional `enabled`, `name`, `simulation_mode` |
| `crowdstrike-falcon_list_ioa_platforms` | List the platforms available for Custom IOA (Indicator of Attack) rule groups in CrowdStrike Falcon (e.g. 'windows', 'mac', 'linux'). | optional `limit`, `offset` |
| `crowdstrike-falcon_list_ioa_rule_groups` | Search and list Custom IOA rule groups in CrowdStrike Falcon with optional FQL filtering. Returns full group details including name, platform, enabled state, and the rules contained in each group. | optional `filter_query`, `limit`, `offset`, `q`, `sort` |
| `crowdstrike-falcon_list_ioa_rule_types` | List the Custom IOA rule type IDs available in CrowdStrike Falcon (e.g. process creation, network connection, file creation, registry operation, domain name). Call this when building a Custom IOA rule to discover which rule types exist. | optional `limit`, `offset` |
| `crowdstrike-falcon_list_ioa_rules` | Search and list Custom IOA rules in CrowdStrike Falcon with optional FQL filtering. Returns full rule details including name, rule type, pattern severity, disposition, field values, and enabled state. | optional `filter_query`, `limit`, `offset`, `q`, `sort` |
| `crowdstrike-falcon_list_iocs` | Search and list custom IOCs (Indicators of Compromise) in CrowdStrike FalconFalcon with FQL filtering. Returns full indicator details including type, value, action, severity, and metadata. | optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_list_it_automation_policies` | List CrowdStrike Falcon IT Automation policies. IT Automation policies govern how automation tasks run on hosts — script/Python/OS Query execution toggles, execution timeouts, and CPU / memory / concurrency resource limits. | optional `limit`, `offset`, `platform`, `sort` |
| `crowdstrike-falcon_list_policy_members` | List the hosts (full device records) governed by a single CrowdStrike Falcon policy, i.e. the policy's members. Supports prevention, sensor_update, device_control, firewall, response, and content_update policies. | **required** `policy_type`, `policy_id`<br />optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_list_prevention_policies` | List CrowdStrike Falcon prevention policies using FQL filters. Prevention policies define security settings for endpoints, including malware protection, behavioral analysis, and threat prevention configurations. | optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_list_response_policies` | List CrowdStrike Falcon Real Time Response (RTR) policies using FQL filters. | optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_list_sensor_policies` | List CrowdStrike Falcon sensor update policies using FQL filters. Sensor update policies control how and when CrowdStrike Falcon sensors are updated on endpoints, including version management and update scheduling. | optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_list_submissions` | Search and list CrowdStrike Falcon Sandbox submissions with FQL filtering. Returns submission status records (state, created_timestamp, sha256, verdict, environment). | optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_perform_host_action` | Take various actions on the hosts in your environment. Contain or lift containment on a host. Hide or unhide a host. Suppress or unsuppress detections. | **required** `action`, `ids` |
| `crowdstrike-falcon_rtr_delete_session` | Delete (close) a CrowdStrike Falcon RTR session by its session ID (requires real-time-response READ scope). Always close sessions when remediation is complete to free the host's RTR slot. | **required** `session_id` |
| `crowdstrike-falcon_rtr_execute_admin_command` | Execute a state-changing (active-responder/admin) RTR command on a host within an active session (requires Real Time Response Admin WRITE scope). Use for remediation that modifies the host. | **required** `session_id`, `base_command`, `command_string` |
| `crowdstrike-falcon_rtr_execute_command` | Execute a read-only RTR command on a host within an active session (requires real-time-response READ scope). Use for investigation/forensics — these commands do not change host state. | **required** `session_id`, `base_command`, `command_string` |
| `crowdstrike-falcon_rtr_get_command_status` | Poll the status and output of a previously-issued RTR command using its cloud_request_id (requires real-time-response READ scope). RTR commands are asynchronous, so this is how you retrieve results. | **required** `cloud_request_id`<br />optional `admin`, `sequence_id` |
| `crowdstrike-falcon_rtr_get_file` | Retrieve a file from a host into the CrowdStrike cloud using the RTR 'get' command (requires Real Time Response Admin WRITE scope). Used to collect forensic artifacts (logs, malware samples) from a compromised host. | **required** `session_id`, `file_path` |
| `crowdstrike-falcon_rtr_init_session` | Initialize a CrowdStrike Falcon Real Time Response (RTR) session against a single managed host (requires real-time-response READ scope). An active session is required before any RTR command can run. | **required** `device_id`<br />optional `queue_offline` |
| `crowdstrike-falcon_rtr_list_put_files` | List the put-file IDs registered in the CrowdStrike cloud that are available to deploy with rtr_put_file (the put_file_name argument). Use this to discover valid put-files before deploying one. | optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_rtr_list_scripts` | List the custom-script IDs available to run with rtr_run_script (the cloud_file argument). Use this to discover valid pre-approved scripts before executing one. Requires the 'Real time response (admin): WRITE' scope. | optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_rtr_put_file` | Upload a file (remediation tool, updated config, cleanup script) onto the remote endpoint via CrowdStrike cloud staging. | **required** `session_id`<br />optional `comment`, `description`, `file_path`, `put_file_name` |
| `crowdstrike-falcon_rtr_run_script` | Run a script on a host via the RTR 'runscript' admin command (requires Real Time Response Admin WRITE scope). Provide exactly one of an inline script (raw_script) or the name of a previously-uploaded custom/cloud script (cloud_file). | **required** `session_id`<br />optional `cloud_file`, `raw_script` |
| `crowdstrike-falcon_search_devices` | Search for devices with full details returned (combines query and details in one call) | optional `filter_query`, `limit`, `offset`, `sort` |
| `crowdstrike-falcon_search_ngsiem` | Execute a CrowdStrike Query Language (CQL) query against CrowdStrike Next-Gen SIEM (NG-SIEM) advanced event search and return the matching event records. | **required** `query_string`<br />optional `end`, `limit`, `repository`, `start`, `timeout_seconds`, `timezone` |
| `crowdstrike-falcon_submit_sample` | Submit a sample for sandbox analysis (sha256, url, or signed source_url). | optional `action_script`, `command_line`, `comment`, `document_password`, `environment_id`, `file_name`, `network_settings`, `sha256`, `source_url`, `submit_name`, `url` |
| `crowdstrike-falcon_trigger_identity_mfa` | Require multi-factor authentication for one or more CrowdStrike Falcon Identity Protection identities by creating a real-time enforcement policy rule (action MFA) scoped to those source users. | **required** `rule_name`, `source_user_entity_ids`<br />optional `simulation_mode`, `trigger` |
| `crowdstrike-falcon_update_alerts` | Perform actions on alerts identified by composite ID(s) in the request. Actions can update status, assignments, comments, and tags. Status values are strings (new, in_progress, reopened, closed). | **required** `ids`<br />optional `add_tags`, `assign_to_name`, `assign_to_user_id`, `assign_to_uuid`, `comment`, `remove_tags`, `remove_tags_by_prefix`, `status`, `unassign` |
| `crowdstrike-falcon_update_cloud_ml_policy` | Configure the Cloud ML and/or Sensor ML machine-learning slider levels within a CrowdStrike Falcon prevention policy. | **required** `policy_id`<br />optional `cloud_ml_detection`, `cloud_ml_prevention`, `sensor_ml_detection`, `sensor_ml_prevention` |
| `crowdstrike-falcon_update_cloud_security_policy` | Update a CrowdStrike Falcon Cloud Security (CSPM) policy setting. Enable or disable the policy, override its severity, and optionally scope the change to specific cloud accounts or regions. | **required** `policy_id`<br />optional `account_ids`, `enabled`, `regions`, `severity`, `tag_excluded` |
| `crowdstrike-falcon_update_content_update_policy` | Update a CrowdStrike Falcon content update policy. Enable or disable the entire policy and/or modify its name, description, and settings. | **required** `policy_id`<br />optional `description`, `enabled`, `name`, `settings` |
| `crowdstrike-falcon_update_device_control_policy` | Update a CrowdStrike Falcon device control (USB) policy. Enable or disable the entire policy and/or modify its name, description, and settings. | **required** `policy_id`<br />optional `description`, `enabled`, `name`, `settings` |
| `crowdstrike-falcon_update_falcon_container_policy` | Update a CrowdStrike Falcon Container image assessment policy. Toggle the policy on/off and/or modify its name, description, and rule set. | **required** `policy_id`<br />optional `description`, `enabled`, `name`, `policy_data` |
| `crowdstrike-falcon_update_ioc` | Update an existing custom IOC in CrowdStrike Falcon. Modify the action, severity, description, expiration, platforms, source, or tags of an indicator. Get the IOC ID from list_iocs first. | **required** `ioc_id`<br />optional `action`, `description`, `expiration`, `platforms`, `severity`, `source`, `tags` |
| `crowdstrike-falcon_update_it_automation_policy` | Update a CrowdStrike Falcon IT Automation policy. Toggle the policy on/off and/or modify its name, description, and execution config. | **required** `policy_id`<br />optional `config`, `description`, `enabled`, `name` |
| `crowdstrike-falcon_update_prevention_policy` | Enable or disable entire CrowdStrike Falcon prevention POLICIES (platform-level policies like "Phase 2 - interim protection", "Detections") by their IDs. | **required** `policy_id`<br />optional `description`, `enabled`, `name`, `settings` |
| `crowdstrike-falcon_update_response_policy` | Update a CrowdStrike Falcon Real Time Response policy. Enable or disable the entire policy and/or modify its name, description, and settings. | **required** `policy_id`<br />optional `description`, `enabled`, `name`, `settings` |
| `crowdstrike-falcon_update_sensor_policy` | Update a CrowdStrike Falcon sensor update policy. Enable or disable the entire policy and/or modify its name, description, and settings (sensor build/version, update scheduler, uninstall protection, variant assignments). | **required** `policy_id`<br />optional `description`, `enabled`, `name`, `settings` |

## Cyble Vision

7 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cyble-vision_add_comment_to_alert` | Add a comment to a Cyble Vision alert (useful for analyst notes, triage status, or linking the alert to a ticket). | **required** `alert_id`, `comment` |
| `cyble-vision_get_cve_details` | Fetch enriched details for a specific CVE from Cyble Vision's vulnerability database — CVSS v2/v3 scores, impact metrics, affected configurations, references, and remediation context. | **required** `cve` |
| `cyble-vision_get_ip_attack_surface` | Fetch Cyble Vision's attack-surface profile for a single IP address tied to a company — open ports, services, certificates, tags, observed vulnerabilities, and risk score. | **required** `company_id`, `ip_address` |
| `cyble-vision_list_companies` | — | — |
| `cyble-vision_list_security_advisories` | — | optional `countries`, `end_date`, `limit`, `order`, `sort_by`, `start_date`, `tags`, `vulnerabilities` |
| `cyble-vision_search_alerts` | — | optional `end_date`, `exclude_status`, `limit`, `service`, `service_raw`, `severity`, `sort_by`, `sort_order`, `start_date`, `status`, `tagged_alert`, `with_data_message` |
| `cyble-vision_search_threat_indicators` | — | optional `end_date`, `indicator_type`, `ioc`, `limit`, `order`, `sort_by`, `start_date` |

## ExtraHop RevealX 360

18 tools. Available as 2 connections: ExtraHop RevealX 360 (OAuth 2.0 client credentials), ExtraHop (Self-Managed) (API key).

| Tool | Description | Arguments |
| --- | --- | --- |
| `extrahop_create_investigation` | Create a new investigation for agent-driven case management, optionally seeding it with associated detection IDs. | **required** `name`<br />optional `assessment`, `assignee`, `detection_ids`, `notes`, `status` |
| `extrahop_download_packets_to_kindo_library` | Search stored packets and download the matching capture (PCAP by default) into the Kindo file library for forensic evidence. Filter by time range, IP, port, and Berkeley Packet Filter (BPF) syntax. | **required** `from_time`<br />optional `bpf`, `ip1`, `ip2`, `limit_bytes`, `limit_search_duration`, `output`, `port1`, `port2`, `until` |
| `extrahop_get_detection` | Get full detail for a single detection by ID, including MITRE tactics/techniques, offender/victim participants, timeline, risk score, and status. | **required** `detection_id` |
| `extrahop_get_device` | Get full detail for a single device by its numeric ID. | **required** `device_id` |
| `extrahop_get_investigation` | Get full detail for a single investigation, including its detections. | **required** `investigation_id` |
| `extrahop_list_detection_investigations` | List all investigations that a specific detection has been added to. | **required** `detection_id` |
| `extrahop_list_detection_types` | List all detection types (formats) known to the system, including display names and MITRE categories, for triage context. | — |
| `extrahop_list_device_activity` | List the protocol activity (client/server roles) observed for a device, for network-peer and blast-radius context. | **required** `device_id` |
| `extrahop_list_device_group_members` | List the devices that belong to a specific device group. | **required** `device_group_id`<br />optional `active_from`, `active_until` |
| `extrahop_list_device_groups` | List all device groups for asset inventory and grouping context. | — |
| `extrahop_list_investigations` | List investigations. Optionally filter by creation/update time or restrict to user-created investigations. | optional `created_after`, `is_user_created`, `updated_after` |
| `extrahop_list_related_detections` | List detections related to a specific detection, for correlation. | **required** `detection_id`<br />optional `from_time`, `until` |
| `extrahop_query_metrics` | Query network and protocol performance metrics for one or more objects over a time window, for anomaly and performance context. Example: metric_category='http_server', metric_name='rsp' for HTTP response counts. | **required** `object_type`, `object_ids`, `metric_category`, `metric_name`, `from_time`<br />optional `cycle`, `until` |
| `extrahop_search_detections` | Search ExtraHop NDR detections with filtering by time range, category, status, risk score, type, and assignee. Returns detection summaries including risk score, MITRE mapping, and participants. Requires the NDR module privilege. | optional `assignee`, `categories`, `from_time`, `limit`, `offset`, `recommended`, `resolutions`, `risk_score_min`, `sort_direction`, `sort_field`, `statuses`, `types`, `until` |
| `extrahop_search_devices` | Search discovered devices by IP, MAC, role, hostname, vendor, tag, discovery ID, criticality, or activity status for asset inventory and blast-radius context. Returns matching device records. | optional `active_from`, `active_until`, `discovery_id`, `hostname`, `ip`, `is_active`, `is_critical`, `limit`, `mac`, `name`, `offset`, `role`, `tag`, `vendor` |
| `extrahop_search_records` | Query transaction-level records (HTTP, DNS, DB, SSL/TLS, DHCP, etc.) for investigation and evidence. Filter with a simple field/operator/operand triple or a raw ExtraHop Query Language (EQL) string. | **required** `from_time`<br />optional `eql`, `filter_field`, `filter_operand`, `filter_operator`, `limit`, `offset`, `record_types`, `sort_direction`, `sort_field`, `until` |
| `extrahop_update_detection` | Update a detection's assignee, status, resolution, or associated ticket ID. Only non-null fields are changed. Note: status 'new' is only accepted when third-party ticket tracking is enabled. | **required** `detection_id`<br />optional `assignee`, `resolution`, `status`, `ticket_id` |
| `extrahop_update_investigation` | Update an investigation's fields and/or associate detections with it. Note: 'detection_ids' REPLACES the full list of associated detections — include existing IDs to keep them. | **required** `investigation_id`<br />optional `assessment`, `assignee`, `detection_ids`, `name`, `notes`, `status` |

## Google Cloud Security

10 tools. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `google-cloud-security_analyze_iam_access` | — | optional `cursor`, `include_inherited`, `limit`, `principal`, `resource` |
| `google-cloud-security_apply_remediation` | — | **required** `resource`, `action`<br />optional `confirm`, `dry_run`, `enabled` |
| `google-cloud-security_delete_resource` | — | **required** `resource`<br />optional `confirm`, `dry_run`, `force_empty_bucket` |
| `google-cloud-security_find_public_exposure` | — | optional `cursor`, `limit`, `projects`, `severity` |
| `google-cloud-security_gcp_api_request` | — | **required** `service`, `path`, `method`<br />optional `confirm`, `dry_run`, `max_items`, `parameters`, `project`, `query` |
| `google-cloud-security_get_resource` | — | **required** `resource_id`<br />optional `include` |
| `google-cloud-security_list_projects` | — | — |
| `google-cloud-security_list_resources` | — | optional `cursor`, `limit`, `projects`, `public_only`, `services` |
| `google-cloud-security_modify_network_access` | — | **required** `resource`, `action`<br />optional `cidr`, `confirm`, `dry_run`, `ports`, `protocol` |
| `google-cloud-security_set_iam_binding` | — | **required** `resource`, `action`, `member`, `role`<br />optional `confirm`, `dry_run` |

## Google Security Operations

55 tools. Credentials are supplied in the connection settings.

| Tool | Description | Arguments |
| --- | --- | --- |
| `google-secops_activate_parser` | Activate a log parser in Google SecOps | **required** `log_type`, `parser_id` |
| `google-secops_create_dashboard` | Create a new dashboard in Google SecOps | **required** `name`<br />optional `access_type`, `description` |
| `google-secops_create_data_table` | Create a new data table in Google SecOps | **required** `name`, `header`<br />optional `description` |
| `google-secops_create_data_table_rows` | Add rows to a data table in Google SecOps | **required** `data_table_id`, `rows` |
| `google-secops_create_feed` | Create a new data feed in Google SecOps | **required** `display_name`, `details` |
| `google-secops_create_parser` | Create a new log parser in Google SecOps | **required** `log_type`, `parser_code`<br />optional `validated_on_empty_logs` |
| `google-secops_create_reference_list` | Create a new reference list in Google SecOps | **required** `name`, `entries`<br />optional `content_type`, `description` |
| `google-secops_create_rule` | Create a new YARA-L detection rule in Google SecOps | **required** `rule_text` |
| `google-secops_deactivate_parser` | Deactivate a log parser in Google SecOps | **required** `log_type`, `parser_id` |
| `google-secops_delete_data_table` | Delete a data table in Google SecOps | **required** `data_table_id` |
| `google-secops_delete_rule` | Delete a detection rule from Google SecOps | **required** `rule_id` |
| `google-secops_disable_feed` | Disable a data feed in Google SecOps | **required** `feed_id` |
| `google-secops_enable_feed` | Enable a data feed in Google SecOps | **required** `feed_id` |
| `google-secops_enable_rule` | Enable or disable a detection rule in Google SecOps | **required** `rule_id`<br />optional `enabled` |
| `google-secops_get_cases` | Get case details by IDs from Google SecOps | **required** `case_ids` |
| `google-secops_get_curated_rule` | Get a specific curated detection rule by ID in Google SecOps | **required** `rule_id` |
| `google-secops_get_curated_rule_by_name` | Search for a curated detection rule by name in Google SecOps | **required** `name` |
| `google-secops_get_curated_rule_set` | Get details of a curated rule set in Google SecOps | **required** `rule_set_id` |
| `google-secops_get_dashboard` | Get dashboard details in Google SecOps | **required** `dashboard_id` |
| `google-secops_get_data_table` | Get data table details in Google SecOps | **required** `data_table_id` |
| `google-secops_get_feed` | Get feed details in Google SecOps | **required** `feed_id` |
| `google-secops_get_log_types` | List all available log types in Google SecOps | — |
| `google-secops_get_parser` | Get parser details in Google SecOps | **required** `log_type`, `parser_id` |
| `google-secops_get_reference_list` | Get reference list details in Google SecOps | **required** `reference_list_id`<br />optional `view` |
| `google-secops_get_rule` | Get a specific detection rule from Google SecOps | **required** `rule_id` |
| `google-secops_get_security_alerts` | Retrieve security alerts from Google SecOps within a time range | **required** `start_time`, `end_time`<br />optional `max_alerts` |
| `google-secops_get_stats` | Get statistics for a UDM query in Google SecOps | **required** `query`, `start_time`, `end_time`<br />optional `max_events` |
| `google-secops_get_threat_intel` | AI-powered threat intelligence query using Google SecOps Gemini | **required** `query` |
| `google-secops_ingest_log` | Ingest a raw log entry into Google SecOps | **required** `log_type`, `log_message` |
| `google-secops_ingest_udm_events` | Ingest UDM-formatted events into Google SecOps | **required** `udm_events` |
| `google-secops_list_curated_rule_sets` | List curated rule set collections in Google SecOps | optional `page_size`, `page_token` |
| `google-secops_list_curated_rules` | List pre-built curated detection rules in Google SecOps | optional `page_size`, `page_token` |
| `google-secops_list_dashboards` | List all dashboards in Google SecOps | optional `page_size` |
| `google-secops_list_data_tables` | List all data tables in Google SecOps | — |
| `google-secops_list_feeds` | List all data feeds in Google SecOps | optional `page_size`, `page_token` |
| `google-secops_list_iocs` | List Indicator of Compromise (IOC) matches from Google SecOps | **required** `start_time`, `end_time`<br />optional `max_matches` |
| `google-secops_list_parsers` | List parsers for a specific log type in Google SecOps | **required** `log_type` |
| `google-secops_list_reference_lists` | List all reference lists in Google SecOps | optional `view` |
| `google-secops_list_rule_detections` | List detections generated by a specific rule in Google SecOps | **required** `rule_id`, `start_time`, `end_time` |
| `google-secops_list_rule_errors` | List execution errors for a detection rule in Google SecOps | **required** `rule_id` |
| `google-secops_list_security_rules` | List all detection rules in Google SecOps | optional `page_size`, `page_token` |
| `google-secops_run_parser` | Test a parser against sample logs in Google SecOps | **required** `log_type`, `parser_code`, `logs`<br />optional `parse_statedump`, `parser_extension_code`, `statedump_allowed` |
| `google-secops_search_curated_detections` | Find detections generated by a curated rule in Google SecOps | **required** `rule_id`, `start_time`, `end_time` |
| `google-secops_search_rule_alerts` | Search for rule-based alerts in Google SecOps | **required** `start_time`, `end_time` |
| `google-secops_search_rules` | Search detection rules by regex pattern in Google SecOps | **required** `query` |
| `google-secops_search_security_events` | Search security events using natural language in Google SecOps | **required** `text`, `start_time`, `end_time`<br />optional `max_events` |
| `google-secops_search_udm` | Search security events using UDM (Unified Data Model) query language in Google SecOps | **required** `query`, `start_time`, `end_time`<br />optional `max_events` |
| `google-secops_summarize_entity` | Get an entity summary with alerts and prevalence data from Google SecOps | **required** `value`, `start_time`, `end_time` |
| `google-secops_translate_nl_to_udm` | Translate natural language text to a UDM query in Google SecOps | **required** `text` |
| `google-secops_update_curated_rule_set_deployment` | Enable or disable a curated rule set deployment in Google SecOps | **required** `category_id`, `rule_set_id`, `precision`, `enabled`<br />optional `alerting` |
| `google-secops_update_feed` | Update feed configuration in Google SecOps | **required** `feed_id`<br />optional `details`, `display_name` |
| `google-secops_update_reference_list` | Update reference list entries in Google SecOps | **required** `reference_list_id`, `entries`<br />optional `description` |
| `google-secops_update_rule` | Update a detection rule's YARA-L text in Google SecOps | **required** `rule_id`, `rule_text` |
| `google-secops_validate_query` | Validate UDM query syntax in Google SecOps | **required** `query` |
| `google-secops_validate_rule` | Validate YARA-L rule syntax in Google SecOps | **required** `rule_text` |

## Graylog

8 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `graylog_create_stream` | Create a new stream | **required** `title`<br />optional `description`, `index_set_id`, `matching_type`, `remove_matches_from_default_stream` |
| `graylog_create_stream_rule` | Create a rule for a stream | **required** `streamId`, `type`, `field`, `value`<br />optional `description`, `inverted` |
| `graylog_get_processing_status` | Get current message processing status | — |
| `graylog_get_stream` | Get details of a specific stream by ID | **required** `streamId` |
| `graylog_get_system_info` | Get Graylog system information including version, node ID, and cluster details | — |
| `graylog_list_streams` | List all available streams | — |
| `graylog_search_messages` | Search for messages using Lucene query syntax with relative time range | **required** `query`, `range`<br />optional `decorate`, `fields`, `filter`, `limit`, `offset`, `sort` |
| `graylog_search_messages_absolute` | Search for messages using Lucene query syntax with absolute time range | **required** `query`, `from`, `to`<br />optional `decorate`, `fields`, `filter`, `limit`, `offset`, `sort` |

## IBM QRadar SIEM

16 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `ibm-qradar_add_offense_note` | Add a text note to a IBM QRadar offense for investigation tracking. | **required** `offense_id`, `note_text` |
| `ibm-qradar_add_reference_set_entry` | Add a value to a IBM QRadar reference data set (e.g., add a malicious IP to a blocklist). | **required** `name`, `value` |
| `ibm-qradar_delete_reference_set_entry` | Remove a value from a IBM QRadar reference data set. | **required** `name`, `value` |
| `ibm-qradar_get_ariel_search` | Check the status of an existing Ariel search and optionally retrieve its results if complete. | **required** `search_id`<br />optional `include_results` |
| `ibm-qradar_get_asset` | Get detailed information about a IBM QRadar asset by its numeric ID. | **required** `asset_id` |
| `ibm-qradar_get_offense` | Get full details of a specific IBM QRadar offense by its numeric ID. Returns all offense fields including source IPs, categories, magnitude, and assigned user. | **required** `offense_id` |
| `ibm-qradar_get_reference_set` | Get the contents of a specific reference data set by name. Returns entries in the set (e.g., list of blocked IPs), paginated by limit. | **required** `name`<br />optional `limit` |
| `ibm-qradar_get_system_info` | Get IBM QRadar system information including version and build number. | — |
| `ibm-qradar_list_closing_reasons` | List available offense closing reasons. Use the returned IDs when closing an offense via update_offense. | optional `limit` |
| `ibm-qradar_list_log_sources` | List configured IBM QRadar log sources with their status, type, and protocol information. | optional `filter_query`, `limit` |
| `ibm-qradar_list_offense_notes` | List notes attached to a specific IBM QRadar offense. | **required** `offense_id`<br />optional `limit` |
| `ibm-qradar_list_offenses` | List IBM QRadar offenses (security incidents) with optional filtering. Returns offenses sorted by most recent. Use the filter parameter for IBM QRadar filter expressions like 'status=OPEN' or 'magnitude >= 5'. | optional `fields`, `filter_query`, `limit`, `status` |
| `ibm-qradar_list_reference_sets` | List IBM QRadar reference data sets (used for IOC management, blocklists, whitelists). Returns set names, types, and element counts. | optional `limit` |
| `ibm-qradar_run_ariel_search` | Execute an AQL (Ariel Query Language) search and return results. The search is submitted, polled until completion, and results are returned. | **required** `query_expression` |
| `ibm-qradar_search_assets` | Search IBM QRadar assets via the asset model REST API. Use the filter parameter for IBM QRadar filter expressions, e.g. 'interfaces contains ip_addresses contains value = "10.0.0.1"'. | optional `fields`, `filter_query`, `limit` |
| `ibm-qradar_update_offense` | Update an offense — close it, hide it, reassign it, or change its status. To close an offense you must provide a closing_reason_id (use list_closing_reasons to find valid IDs). | **required** `offense_id`<br />optional `assigned_to`, `closing_reason_id`, `follow_up`, `status` |

## Microsoft Defender

18 tools. Available as 2 connections: Microsoft Defender (OAuth 2.0), Microsoft Defender for Endpoint (GCC High) (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-defender_create_indicator` | Create or update a Microsoft Defender threat indicator (IP, URL, domain, or file hash) with a specified action | **required** `indicator_value`, `indicator_type`, `action`, `title`<br />optional `description`, `expiration_time`, `generate_alert`, `severity` |
| `microsoft-defender_delete_indicator` | Delete a Microsoft Defender threat indicator by ID | **required** `indicator_id` |
| `microsoft-defender_get_alert` | Get a single Microsoft Defender alert by ID with full detail | **required** `alert_id` |
| `microsoft-defender_get_incident` | Get a Microsoft Defender incident by ID including associated alerts | **required** `incident_id` |
| `microsoft-defender_get_indicator` | Get a specific Microsoft Defender threat indicator by ID | **required** `indicator_id` |
| `microsoft-defender_get_investigation` | Get a Microsoft Defender automated investigation by ID | **required** `investigation_id` |
| `microsoft-defender_get_machine` | Get a single Microsoft Defender endpoint device by ID | **required** `machine_id` |
| `microsoft-defender_isolate_machine` | Isolate a device from the network. Use Full for complete network cutoff or Selective for limited isolation | **required** `machine_id`, `comment`<br />optional `isolation_type` |
| `microsoft-defender_list_alerts` | List Microsoft Defender alerts with filtering by status, severity, and OData expressions | optional `filter_query`, `severity`, `skip`, `status`, `top` |
| `microsoft-defender_list_incidents` | List Microsoft Defender security incidents with filtering by status, assignment, and OData expressions | optional `assigned_to`, `filter_query`, `skip`, `status`, `top` |
| `microsoft-defender_list_indicators` | List Microsoft Defender threat indicators with OData filtering by type, action, and other properties | optional `filter_query`, `skip`, `top` |
| `microsoft-defender_list_investigations` | List Microsoft Defender automated investigations with OData filtering by state and machine | optional `filter_query`, `skip`, `top` |
| `microsoft-defender_list_machines` | List Microsoft Defender endpoint devices with OData filtering by DNS name, OS platform, risk score, and health status | optional `filter_query`, `skip`, `top` |
| `microsoft-defender_run_advanced_query` | Execute a KQL (Kusto Query Language) query against Microsoft Defender data for advanced threat hunting | **required** `query` |
| `microsoft-defender_run_antivirus_scan` | Initiate an antivirus scan on a device. Use Quick for a fast scan or Full for a comprehensive scan | **required** `machine_id`, `comment`<br />optional `scan_type` |
| `microsoft-defender_unisolate_machine` | Release a device from network isolation, restoring its network connectivity | **required** `machine_id`, `comment` |
| `microsoft-defender_update_alert` | Update a Microsoft Defender alert's status, assignment, classification, or determination | **required** `alert_id`<br />optional `assigned_to`, `classification`, `comment`, `determination`, `status` |
| `microsoft-defender_update_incident` | Update a Microsoft Defender incident's status, assignment, classification, tags, or determination | **required** `incident_id`<br />optional `assigned_to`, `classification`, `comment`, `determination`, `status`, `tags` |

## Microsoft Graph Security

16 tools. Available as 4 connections: Microsoft Graph Security (OAuth 2.0), Microsoft Graph Security (Application) (OAuth 2.0 client credentials), Microsoft Graph Security (GCC High) (OAuth 2.0), Microsoft Defender XDR (GCC High, Application) (OAuth 2.0 client credentials).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-graph-security_confirm_risky_users_compromised` | Confirm one or more users as compromised, setting their risk level to high | **required** `user_ids` |
| `microsoft-graph-security_confirm_risky_users_safe` | Confirm one or more users as safe, setting their risk level to none | **required** `user_ids` |
| `microsoft-graph-security_create_alert_comment` | Add a comment to an existing security alert | **required** `alert_id`, `comment` |
| `microsoft-graph-security_create_incident_comment` | Add a comment to an existing security incident | **required** `incident_id`, `comment` |
| `microsoft-graph-security_dismiss_risky_users` | Dismiss (reset) the risk of one or more users, setting their risk level to none | **required** `user_ids` |
| `microsoft-graph-security_get_alert` | Get a single security alert by ID, including evidence artifacts and MITRE ATT&CK techniques | **required** `alert_id` |
| `microsoft-graph-security_get_incident` | Get a single security incident by ID, optionally expanding related alerts | **required** `incident_id`<br />optional `expand_alerts` |
| `microsoft-graph-security_get_risky_user` | Get a single risky user by ID from Microsoft Entra ID Identity Protection | **required** `risky_user_id` |
| `microsoft-graph-security_list_alerts` | List security alerts from Microsoft 365 Defender with filtering by severity, status, classification, service source, assignee, and date range | optional `assigned_to`, `classification`, `created_after`, `created_before`, `service_source`, `severity`, `skip`, `status`, `top` |
| `microsoft-graph-security_list_incidents` | List security incidents from Microsoft 365 Defender with filtering by severity, status, classification, assignee, and date range | optional `assigned_to`, `classification`, `created_after`, `created_before`, `severity`, `skip`, `status`, `top` |
| `microsoft-graph-security_list_risky_users` | List risky users from Microsoft Entra ID Identity Protection with filtering by risk level, risk state, and user principal name | optional `risk_level`, `risk_state`, `skip`, `top`, `user_principal_name` |
| `microsoft-graph-security_list_secure_score_control_profiles` | List individual security control profiles with their scores and improvement actions | optional `skip`, `top` |
| `microsoft-graph-security_list_secure_scores` | List tenant security scores (daily snapshots) from Microsoft Secure Score | optional `skip`, `top` |
| `microsoft-graph-security_run_hunting_query` | Execute a KQL query against Microsoft 365 Defender raw data (up to 30 days, max 100K rows) | **required** `query`<br />optional `timespan` |
| `microsoft-graph-security_update_alert` | Update a security alert's status, assignee, classification, and determination | **required** `alert_id`<br />optional `assigned_to`, `classification`, `determination`, `status` |
| `microsoft-graph-security_update_incident` | Update a security incident's status, assignee, classification, determination, and custom tags | **required** `incident_id`<br />optional `assigned_to`, `classification`, `custom_tags`, `determination`, `status` |

## Microsoft Sentinel (Management)

12 tools. Available as 2 connections: Microsoft Sentinel (Management) (OAuth 2.0), Microsoft Sentinel (Management, Government) (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-sentinel-management_add_incident_comment` | Add an analyst comment to a Microsoft Sentinel incident, for recording investigation notes and handoffs on the incident timeline. Each call appends a new comment. Returns an acknowledgement {'id', 'incident_id', 'created'}. | **required** `incident_id`, `message` |
| `microsoft-sentinel-management_create_bookmark` | Create a Microsoft Sentinel hunting bookmark to preserve a notable KQL query result during an investigation. Requires a display name and the KQL query text; notes are optional context. Each call creates a new bookmark. | **required** `display_name`, `query`<br />optional `notes` |
| `microsoft-sentinel-management_get_incident` | Get the details of a single Microsoft Sentinel incident by its ID (the 'id' field from list_incidents), including its description, severity, status, owner, labels, classification, and MITRE tactics/techniques. | **required** `incident_id` |
| `microsoft-sentinel-management_get_watchlist` | Get a single Microsoft Sentinel watchlist by its alias (the 'alias' field from list_watchlists), including its source, provider, search key, and authorship. Returns metadata only — call list_watchlist_items for the rows. | **required** `watchlist_alias` |
| `microsoft-sentinel-management_list_bookmarks` | List Microsoft Sentinel hunting bookmarks in the workspace. Bookmarks preserve interesting query results found during threat hunting so analysts can revisit and share them. | optional `cursor`, `top` |
| `microsoft-sentinel-management_list_incident_alerts` | List the security alerts grouped into a Microsoft Sentinel incident — the underlying detections that make up the case. | **required** `incident_id`<br />optional `cursor`, `top` |
| `microsoft-sentinel-management_list_incident_entities` | List the entities (accounts, hosts, IPs, files, URLs, etc.) related to a Microsoft Sentinel incident — use it to scope an investigation to the affected assets and identities. | **required** `incident_id`<br />optional `top` |
| `microsoft-sentinel-management_list_incidents` | List Microsoft Sentinel incidents for the connected workspace, newest first. Incidents group related alerts into a single investigatable case. | optional `cursor`, `severity`, `status`, `top` |
| `microsoft-sentinel-management_list_threat_intelligence_indicators` | List threat-intelligence indicators (IOCs) in the Microsoft Sentinel workspace — IPs, domains, URLs, file hashes, and more, with their confidence, validity window, and threat types. | optional `cursor`, `top` |
| `microsoft-sentinel-management_list_watchlist_items` | List the individual rows of a Microsoft Sentinel watchlist. | **required** `watchlist_alias`<br />optional `cursor`, `top` |
| `microsoft-sentinel-management_list_watchlists` | List Microsoft Sentinel watchlists in the workspace. Watchlists are curated reference datasets (e.g. high-value assets, allowed IPs, terminated employees) used to correlate and enrich detections. | optional `cursor`, `top` |
| `microsoft-sentinel-management_update_incident` | Update a Microsoft Sentinel incident: change its title, severity, status, or close it. Only the fields you provide are changed; the rest are preserved. | **required** `incident_id`<br />optional `classification`, `classification_comment`, `classification_reason`, `severity`, `status`, `title` |

## MITRE ATT&CK

8 tools. Credentials are supplied in the connection settings.

| Tool | Description | Arguments |
| --- | --- | --- |
| `mitre-attack_list_tactics` | List all MITRE ATT&CK tactics for a matrix in kill-chain order. | optional `matrix` |
| `mitre-attack_list_techniques_for_tactic` | — | **required** `tactic`<br />optional `include_deprecated`, `include_revoked`, `include_subtechniques`, `limit`, `matrix`, `offset` |
| `mitre-attack_lookup_campaign` | Look up a MITRE ATT&CK campaign by ATT&CK ID (e.g. 'C0028') or name. Searches all matrices. | optional `campaign_id`, `include_deprecated`, `include_revoked`, `query` |
| `mitre-attack_lookup_group` | Look up a MITRE ATT&CK threat group (intrusion set) by ATT&CK ID (e.g. 'G0007'), name, or alias (e.g. 'APT28', 'Fancy Bear', 'STRONTIUM'). Searches all matrices. | optional `group_id`, `include_deprecated`, `include_revoked`, `query` |
| `mitre-attack_lookup_mitigation` | Look up a MITRE ATT&CK mitigation (course of action) by ATT&CK ID (e.g. 'M1056') or keyword. Returns the mitigation profile plus an inline summary of every technique the mitigation is mapped to. | optional `include_deprecated`, `include_revoked`, `matrix`, `mitigation_id`, `query` |
| `mitre-attack_lookup_software` | Look up MITRE ATT&CK software (malware or tool) by ATT&CK ID (e.g. 'S0002') or name. Searches all matrices. | optional `include_deprecated`, `include_revoked`, `query`, `software_id` |
| `mitre-attack_lookup_technique` | Look up a MITRE ATT&CK technique (or sub-technique) by ATT&CK ID (e.g. 'T1059' or 'T1059.001') or keyword. | optional `include_deprecated`, `include_revoked`, `matrix`, `query`, `technique_id` |
| `mitre-attack_search_attack` | Free-text search across the MITRE ATT&CK knowledge base. Searches names, descriptions, aliases, and ATT&CK IDs of techniques, tactics, mitigations, threat groups, software, campaigns, data sources, data components, and ICS assets. | **required** `query`<br />optional `include_deprecated`, `include_revoked`, `limit`, `matrix`, `object_types`, `offset` |

## Obsidian Security

0 tools. Connect with API key.

## Palo Alto Cortex XDR

19 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `palo-alto-cortex-xdr_allowlist_files` | Add file hashes to the Cortex XDR allowlist to exclude them from security scanning | **required** `hash_list`<br />optional `comment`, `incident_id` |
| `palo-alto-cortex-xdr_blocklist_files` | Add file hashes to the Cortex XDR blocklist to prevent execution across all endpoints | **required** `hash_list`<br />optional `comment`, `incident_id` |
| `palo-alto-cortex-xdr_get_action_status` | Check the status of a response action (isolate, scan, script execution, etc.) | **required** `action_id` |
| `palo-alto-cortex-xdr_get_audit_management_logs` | Retrieve Cortex XDR audit management logs with filtering by admin email, type, result, and timestamp | optional `email`, `log_type`, `result`, `search_from`, `search_to`, `sort_field`, `sort_order`, `timestamp_gte`, `timestamp_lte` |
| `palo-alto-cortex-xdr_get_incident` | Get detailed incident data including alerts, network artifacts, and file artifacts for a specific incident | **required** `incident_id`<br />optional `alerts_limit` |
| `palo-alto-cortex-xdr_get_script_execution_results` | Get the results of a previously executed script using the action ID | **required** `action_id` |
| `palo-alto-cortex-xdr_get_xql_results` | Retrieve results of a previously started XQL query using the query ID | **required** `query_id`<br />optional `limit` |
| `palo-alto-cortex-xdr_insert_alerts` | Insert externally-detected alerts into Cortex XDR for correlation and investigation | **required** `alerts` |
| `palo-alto-cortex-xdr_isolate_endpoint` | Isolate an endpoint from the network to contain a threat (endpoint remains manageable via Cortex XDR) | **required** `endpoint_id`<br />optional `incident_id` |
| `palo-alto-cortex-xdr_list_alerts` | List Cortex XDR alerts with filtering by alert ID, source, severity, and creation time | optional `alert_id_list`, `alert_source`, `creation_time_gte`, `creation_time_lte`, `search_from`, `search_to`, `severity`, `sort_field`, `sort_order` |
| `palo-alto-cortex-xdr_list_endpoints` | List Cortex XDR endpoints with filtering by status, hostname, IP, platform, isolation status, and more | optional `alias`, `endpoint_id_list`, `endpoint_status`, `group_name`, `hostname`, `ip_list`, `isolate`, `platform`, `search_from`, `search_to`, `sort_field`, `sort_order`, `username` |
| `palo-alto-cortex-xdr_list_incidents` | List Cortex XDR incidents with filtering by status, severity, creation/modification time, and description | optional `creation_time_gte`, `creation_time_lte`, `description`, `incident_id_list`, `modification_time_gte`, `search_from`, `search_to`, `severity`, `sort_field`, `sort_order`, `status` |
| `palo-alto-cortex-xdr_list_scripts` | List available scripts in the Cortex XDR script library with optional filtering | optional `description`, `is_high_risk`, `linux_supported`, `macos_supported`, `name`, `search_from`, `search_to`, `windows_supported` |
| `palo-alto-cortex-xdr_quarantine_file` | Quarantine a file on an endpoint by path and SHA256 hash to prevent execution | **required** `endpoint_id`, `file_path`, `file_hash`<br />optional `incident_id` |
| `palo-alto-cortex-xdr_run_script` | Execute a script from the Cortex XDR library on one or more endpoints | **required** `script_uid`, `endpoint_id_list`<br />optional `incident_id`, `parameters_values`, `timeout` |
| `palo-alto-cortex-xdr_scan_endpoints` | Initiate a malware scan on specified endpoints or all endpoints | optional `all_endpoints`, `dist_name`, `endpoint_id_list` |
| `palo-alto-cortex-xdr_start_xql_query` | Start an XQL (XDR Query Language) query for advanced threat hunting and data analysis | **required** `query`<br />optional `tenants`, `time_frame` |
| `palo-alto-cortex-xdr_unisolate_endpoint` | Restore network connectivity for a previously isolated endpoint | **required** `endpoint_id`<br />optional `incident_id` |
| `palo-alto-cortex-xdr_update_incident` | Update an incident's status, severity, assignee, or add a resolve comment | **required** `incident_id`<br />optional `assigned_user_mail`, `assigned_user_pretty_name`, `resolve_comment`, `severity`, `status` |

## Proofpoint Email Protection

8 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `proofpoint_delete_quarantine_message` | Delete a quarantined message by moving it to the deleted folder. Identified by quarantine folder and local GUID. This is destructive. | **required** `folder`, `local_guid`<br />optional `deleted_folder` |
| `proofpoint_forward_quarantine_message` | Forward a copy of a quarantined message to another recipient for review, without releasing it to the original recipients. | **required** `folder`, `local_guid`, `to` |
| `proofpoint_get_end_user` | Get an end-user's Proofpoint profile, including their safe-sender and blocked-sender lists. Identified by email address or user id. | **required** `email_or_uid` |
| `proofpoint_list_quarantine_messages` | List messages currently held in a Proofpoint quarantine folder. Filter by sender, recipient, subject, date range, or folder. | optional `end_date`, `folder`, `limit`, `message_status`, `recipient`, `sender`, `start_date`, `subject` |
| `proofpoint_move_quarantine_message` | Move a quarantined message from one quarantine folder to another. Identified by source folder and local GUID. | **required** `folder`, `local_guid`, `target_folder` |
| `proofpoint_release_quarantine_message` | Release a quarantined message back to its recipients. The message is identified by its quarantine folder and local GUID. This delivers the held email — use after confirming it is safe. | **required** `folder`, `local_guid`<br />optional `rescan` |
| `proofpoint_resubmit_quarantine_message` | Resubmit a quarantined message back through the filtering modules for re-evaluation. Identified by quarantine folder and local GUID. | **required** `folder`, `local_guid` |
| `proofpoint_search_messages` | Search processed email through Proofpoint Smart Search. Filter by envelope sender/recipient, time window, subject, message-id, or final disposition to trace a message and inspect its spam/phishing/virus verdict. | optional `disposition`, `end_date`, `limit`, `message_id`, `recipient`, `sender`, `start_date`, `subject`, `virus` |

## Rapid7 InsightIDR

15 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `rapid7-insightidr_add_threat_indicators` | Add IP, hash, domain, or URL indicators to an InsightIDR threat | **required** `key`<br />optional `domain_names`, `hashes`, `ips`, `urls` |
| `rapid7-insightidr_create_comment` | Add a comment to an InsightIDR investigation | **required** `target`, `body` |
| `rapid7-insightidr_create_investigation` | Create a new manual InsightIDR investigation with title, priority, and status | **required** `title`<br />optional `assignee_email`, `disposition`, `priority`, `status` |
| `rapid7-insightidr_get_investigation` | Get details of a specific InsightIDR investigation by ID or RRN | **required** `investigation_id` |
| `rapid7-insightidr_list_comments` | List comments for a specific InsightIDR investigation | **required** `target`<br />optional `index`, `size` |
| `rapid7-insightidr_list_detection_rules` | List InsightIDR detection rules with pagination. Note: requires appropriate SIEM tier permissions. Raises a not-found error if your API key lacks detection rule access. | optional `index`, `size` |
| `rapid7-insightidr_list_investigation_alerts` | List alerts associated with a specific InsightIDR investigation | **required** `investigation_id`<br />optional `index`, `size` |
| `rapid7-insightidr_list_investigations` | List InsightIDR investigations with filtering by status, priority, assignee, and time range | optional `assignee_email`, `end_time`, `index`, `priorities`, `size`, `sort`, `sources`, `start_time`, `statuses` |
| `rapid7-insightidr_list_logs` | List all available log sources in InsightIDR | — |
| `rapid7-insightidr_list_users` | Search and list InsightIDR user accounts | optional `index`, `search`, `size` |
| `rapid7-insightidr_query_log` | Execute a LEQL query against a specific InsightIDR log source | **required** `log_id`, `query`<br />optional `end_time`, `start_time`, `time_range` |
| `rapid7-insightidr_search_alerts` | Search InsightIDR alerts with filtering by status and time range. Note: requires the Managed Detection and Response (MDR) add-on. Raises a not-found error if your account does not have MDR access. | optional `end_time`, `index`, `search`, `size`, `start_time`, `statuses` |
| `rapid7-insightidr_search_investigations` | Search InsightIDR investigations by text query with time range filtering | optional `end_time`, `index`, `search`, `size`, `sort`, `start_time` |
| `rapid7-insightidr_update_alert` | Update an InsightIDR alert's status, disposition, priority, or assignment. Note: requires the Managed Detection and Response (MDR) add-on. Raises a not-found error if your account does not have MDR access. | **required** `alert_id`<br />optional `assignee_email`, `disposition`, `priority`, `status` |
| `rapid7-insightidr_update_investigation` | Update an InsightIDR investigation's title, status, priority, disposition, or assignee | **required** `investigation_id`<br />optional `assignee_email`, `disposition`, `priority`, `status`, `title` |

## Recorded Future

14 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `recorded-future_enrich_domain` | Enrich a domain with Recorded Future threat intelligence including risk score, risk rules, evidence details, and related entity links | **required** `domain`<br />optional `fields` |
| `recorded-future_enrich_entities` | Bulk enrich multiple entities (IPs, domains, URLs, hashes, vulnerabilities) at once using the SOAR API. More efficient than individual enrichment calls when checking multiple indicators. | optional `domain`, `file_hash`, `ip`, `url`, `vulnerability` |
| `recorded-future_enrich_hash` | Enrich a file hash (MD5, SHA-1, or SHA-256) with Recorded Future threat intelligence including risk score, risk rules, and malware associations | **required** `file_hash`<br />optional `fields` |
| `recorded-future_enrich_ip` | Enrich an IP address with Recorded Future threat intelligence including risk score, risk rules, evidence details, and related entity links | **required** `ip`<br />optional `fields` |
| `recorded-future_enrich_url` | Enrich a URL with Recorded Future threat intelligence including risk score, risk rules, and evidence details | **required** `url`<br />optional `fields` |
| `recorded-future_enrich_vulnerability` | Enrich a vulnerability (CVE ID or name) with Recorded Future threat intelligence including risk score, risk rules, evidence, and exploit availability | **required** `vulnerability_id`<br />optional `fields` |
| `recorded-future_get_alert` | Get detailed information about a specific triggered alert by ID, including hits, entities, documents, risk scores, and AI insights | **required** `alert_id`<br />optional `fields` |
| `recorded-future_get_playbook_alert` | Get detailed information about a specific playbook alert by ID, including evidence summary, targets, priority, and category details | **required** `alert_id` |
| `recorded-future_get_threat_map_actors` | Get threat actor map data for the organization, showing threat actors with intent and opportunity scores, categories, and watchlist matches. Useful for understanding the threat landscape targeting your organization. | **required** `actors`, `categories`, `watchlists` |
| `recorded-future_get_threat_map_malware` | Get malware threat map data for the organization, showing malware families with severity scores, categories, and watchlist matches. Useful for understanding malware threats targeting your organization. | **required** `malware`, `categories`, `watchlists` |
| `recorded-future_search_alert_rules` | Search Recorded Future alert rules by name. Returns rule titles and IDs for use with alert search filtering. | optional `freetext`, `limit` |
| `recorded-future_search_alerts` | Search triggered alerts in Recorded Future with filtering by timeframe, alert rule, and pagination. Returns alert summaries including title, rule, status, and hit counts. | optional `alert_rule`, `fields`, `limit`, `offset`, `triggered` |
| `recorded-future_search_detection_rules` | Search Recorded Future detection rules (Sigma, Yara, Snort) with filtering by type, related entities, and date range. Returns rules with content for import into security tools. | optional `after`, `before`, `entities`, `limit`, `types` |
| `recorded-future_search_playbook_alerts` | Search Recorded Future playbook alerts with filtering by status, priority, category, and time ranges. Returns actionable security alerts with triage information. | optional `categories`, `created_from_relative`, `entities`, `limit`, `priorities`, `statuses`, `updated_from_relative` |

## ReliaQuest GreyMatter

22 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `reliaquest-greymatter_acknowledge_incident` | Acknowledge a Grey Matter incident by providing acknowledgement method and auto-assignment preference. Use the base64-encoded incident ID | **required** `input` |
| `reliaquest-greymatter_add_incident_comment` | Add a comment to a Grey Matter incident by providing the comment text and incident ID. Use the base64-encoded incident ID | **required** `input`<br />optional `after`, `filter`, `first`, `order` |
| `reliaquest-greymatter_assign_incident` | Assign a Grey Matter incident to a specific user by providing the assignee ID and incident ID. FIRST use list_users to find the user ID by email/name, THEN assign the incident. Use the base64-encoded incident ID | **required** `input` |
| `reliaquest-greymatter_close_incident` | Close a Grey Matter incident by providing the close code, close note, incident ID, and optional final state. Use the base64-encoded incident ID | **required** `request` |
| `reliaquest-greymatter_get_audits` | Retrieve user activity audits with comprehensive filtering and pagination support. For time-based queries, use exec tool to get current date first. | optional `after`, `filter`, `first`, `order` |
| `reliaquest-greymatter_get_customer_detection` | Retrieve a specific Grey Matter customer detection with activity logs and rule details. For date filtering, use exec tool to get current date first. | **required** `id`, `by`<br />optional `after`, `filter`, `first`, `order` |
| `reliaquest-greymatter_get_incident` | Retrieve a specific Grey Matter incident by ID or ticket number with all related data. For date filtering, use exec tool to get current date first. | **required** `by`<br />optional `after`, `after4`, `filter`, `filter5`, `first`, `first4`, `order`, `order4` |
| `reliaquest-greymatter_get_indicator` | Retrieve a specific Grey Matter indicator by Global ID or name/type combination | **required** `by` |
| `reliaquest-greymatter_get_playbook_run` | Retrieve a specific Grey Matter playbook run with execution results, user details, and complete audit trail | **required** `id`<br />optional `after`, `after1`, `after2`, `after3`, `after4`, `after5`, `after6`, `after7`, `filter`, `filter1`, `filter2`, `filter3`, `filter4`, `filter5`, `first`, `first1`, `first2`, `first3`, `first4`, `first5`, `first6`, `first7`, `order`, `order1`, `order2`, `order3`, `order4`, `order5` |
| `reliaquest-greymatter_get_playbook_run_filter_data` | Get available filter values for playbook runs including tempRuleIds, ticketNumbers, and users | optional `after`, `after1`, `after2`, `filter`, `filter1`, `filter2`, `first`, `first1`, `first2`, `order`, `order1`, `order2` |
| `reliaquest-greymatter_get_recommended_playbooks` | Get recommended Grey Matter playbooks based on artifacts and temporary rule ID. Use single artifact object with field and values array, not array of artifacts. | **required** `filter` |
| `reliaquest-greymatter_get_user` | Retrieve a specific Grey Matter user by ID with comprehensive access groups, pods, and roles information | **required** `id`<br />optional `after`, `after1`, `after2`, `filter`, `filter1`, `filter2`, `first`, `first1`, `first2`, `order`, `order1`, `order2` |
| `reliaquest-greymatter_list_customer_detections` | Fetch all Grey Matter customer detections matching filter criteria with pagination. For date filtering, use exec tool to get current date first in ISO 8601 format with a Z suffix for UTC timezone (e.g., 2025-06-22T00:00:00Z). | optional `after`, `filter`, `first`, `order` |
| `reliaquest-greymatter_list_customer_playbooks` | Get all Grey Matter customer playbooks with their configurations and supported integrations | — |
| `reliaquest-greymatter_list_detection_rules` | Fetch all Grey Matter detection rules matching filter criteria with comprehensive filtering, ordering, and pagination support. | optional `after`, `detectionRuleOrder`, `filter`, `first` |
| `reliaquest-greymatter_list_incidents` | Fetch all Grey Matter incidents matching filter criteria with pagination. For date filtering, use exec tool to get current date first in ISO 8601 format with a Z suffix for UTC timezone (e.g., 2025-06-22T00:00:00Z). | optional `after`, `first`, `incidentFilter`, `incidentOrder` |
| `reliaquest-greymatter_list_indicators` | Fetch all Grey Matter indicators matching filter criteria with pagination. For date filtering, use exec tool to get current date first in ISO 8601 format with a Z suffix for UTC timezone (e.g., 2025-06-22T00:00:00Z). | optional `after`, `filter`, `first`, `order` |
| `reliaquest-greymatter_list_playbook_runs` | Get Grey Matter playbook runs with comprehensive filtering, pagination, and sorting options. For date filtering, use exec tool to get current date first in ISO 8601 format with a Z suffix for UTC timezone (e.g., 2025-06-22T00:00:00Z). | optional `after`, `filter`, `first`, `orderBy` |
| `reliaquest-greymatter_list_playbooks` | Get all available Grey Matter playbooks with their metadata, field definitions, and supported technologies | — |
| `reliaquest-greymatter_list_users` | Retrieve users for the current customer organization with pagination support. Returns customer info and paginated user list including id, email, fullName, and serviceNowId. | optional `after`, `first` |
| `reliaquest-greymatter_run_playbook` | Execute a Grey Matter playbook with specified configuration, integration IDs, and variables. Used to trigger automated response actions. | **required** `input` |
| `reliaquest-greymatter_update_incident_state` | Update the state of a Grey Matter incident by providing a comment explaining the change, incident ID, and new state. Use the base64-encoded incident ID, not the ticket number. Returns incident state details and success status. | **required** `input` |

## SentinelOne

22 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `sentinelone_get_alert` | Get detailed information about a specific alert by ID. Args: alert_id: The unique identifier of the alert. Returns: Detailed alert information in JSON format. Raises: RuntimeError: If there's an error retrieving the alert. | **required** `alert_id` |
| `sentinelone_get_alert_history` | Get the complete audit history and timeline for an alert. Args: alert_id: The unique identifier of the alert. first: Number of history events to retrieve (1-100, default: 10). after: Cursor for pagination (optional). | **required** `alert_id`<br />optional `after`, `first` |
| `sentinelone_get_alert_notes` | Get all notes and comments associated with an alert. Args: alert_id: The unique identifier of the alert. Returns: List of notes in JSON format with author and timestamp information. | **required** `alert_id` |
| `sentinelone_get_inventory_item` | Get detailed information about a specific inventory item by ID. Args: item_id: The unique identifier of the inventory item. Returns: Detailed inventory item information in JSON format. Raises: ValueError: If item_id is invalid or empty. | **required** `item_id` |
| `sentinelone_get_misconfiguration` | Get detailed information about a specific misconfiguration by ID. Args: misconfiguration_id: The unique identifier of the misconfiguration. Returns: Detailed misconfiguration information in JSON format. | **required** `misconfiguration_id` |
| `sentinelone_get_misconfiguration_history` | Get the audit history for a misconfiguration. Args: misconfiguration_id: The unique identifier of the misconfiguration. first: Number of history events to retrieve (1-100, default: 10). after: Cursor for pagination (optional). | **required** `misconfiguration_id`<br />optional `after`, `first` |
| `sentinelone_get_misconfiguration_notes` | Get all notes associated with a misconfiguration. Args: misconfiguration_id: The unique identifier of the misconfiguration. Returns: List of notes in JSON format. | **required** `misconfiguration_id` |
| `sentinelone_get_timestamp_range` | Get both current timestamp and offset timestamp for time range queries. This tool returns both the current time and a calculated offset time, designed specifically for PowerQuery time range queries. | optional `days`, `direction`, `hours`, `minutes`, `months`, `reference_time`, `seconds`, `weeks`, `years` |
| `sentinelone_get_vulnerability` | Get detailed information about a specific vulnerability by ID. Args: vulnerability_id: The unique identifier of the vulnerability. Returns: Detailed vulnerability information in JSON format. | **required** `vulnerability_id` |
| `sentinelone_get_vulnerability_history` | Get the audit history for a vulnerability. Args: vulnerability_id: The unique identifier of the vulnerability. first: Number of history events to retrieve (1-100, default: 10). after: Cursor for pagination (optional). | **required** `vulnerability_id`<br />optional `after`, `first` |
| `sentinelone_get_vulnerability_notes` | Get all notes associated with a vulnerability. Args: vulnerability_id: The unique identifier of the vulnerability. Returns: List of notes in JSON format. Raises: RuntimeError: If there's an error retrieving vulnerability notes. | **required** `vulnerability_id` |
| `sentinelone_iso_to_unix_timestamp` | Convert an ISO 8601 datetime string to UNIX timestamp in milliseconds. Args: iso_datetime: ISO 8601 formatted datetime string. Returns: UNIX timestamp in milliseconds as a string. | **required** `iso_datetime` |
| `sentinelone_list_alerts` | List alerts with pagination and filtering capabilities. Args: first: Number of alerts to retrieve (1-100, default: 10). after: Cursor for pagination (optional). | optional `after`, `fields`, `first`, `view_type` |
| `sentinelone_list_inventory_items` | List inventory items with pagination and optional surface filtering. Args: limit: Number of items to retrieve (1-1000, default: 50). skip: Number of items to skip for pagination (default: 0). | optional `limit`, `skip`, `surface` |
| `sentinelone_list_misconfigurations` | List misconfigurations with pagination and view filtering. Args: first: Number of misconfigurations to retrieve (1-100, default: 10). after: Cursor for pagination (optional). | optional `after`, `fields`, `first`, `view_type` |
| `sentinelone_list_vulnerabilities` | List vulnerabilities with pagination. Args: first: Number of vulnerabilities to retrieve (1-100, default: 10). after: Cursor for pagination (optional). fields: Optional JSON string containing an array of field names to return. | optional `after`, `fields`, `first` |
| `sentinelone_powerquery` | Run a SentinelOne PowerQuery in AISIEM and return the results. Args: query: The PowerQuery string to execute start_datetime: Start time in ISO 8601 format. | **required** `query`, `start_datetime`, `end_datetime` |
| `sentinelone_purple_ai` | Ask Purple AI a question. Purple AI is a tool to answer cyber security questions. Args: query: The question to ask Purple AI. Returns: The response from Purple AI as a string. Raises: RuntimeError: If settings are not properly configured. | **required** `query` |
| `sentinelone_search_alerts` | Search alerts using advanced filters and criteria. Args: filters: JSON string containing an array of filter objects (optional). Each filter object must have fieldId and filterType keys. | optional `after`, `fields`, `filters`, `first`, `view_type` |
| `sentinelone_search_inventory_items` | Search inventory items using REST API filters. Note: This tool does not support surface filtering. For surface-specific queries (ENDPOINT, CLOUD, IDENTITY, NETWORK_DISCOVERY), use list_inventory_items instead. | optional `filters`, `limit`, `skip` |
| `sentinelone_search_misconfigurations` | Search misconfigurations using advanced filters and criteria. Args: filters: JSON string containing an array of filter objects (optional). Each filter object must have fieldId and filterType keys. | optional `after`, `fields`, `filters`, `first`, `view_type` |
| `sentinelone_search_vulnerabilities` | Search vulnerabilities using advanced filters and criteria. Args: filters: JSON string containing an array of filter objects (optional). Each filter object must have fieldId and filterType keys. | optional `after`, `fields`, `filters`, `first` |

## Splunk

26 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `splunk_add_investigation_note` | Add a free-form note to a Splunk ES Mission Control v2 record via the unified notes endpoint (`POST /servicesNS/nobody/missioncontrol/public/v2/investigations/{id}/notes`). | **required** `investigation_id`, `content`<br />optional `notable_time`, `title` |
| `splunk_cancel_job` | Cancel a running search job | **required** `sid` |
| `splunk_create_finding` | Create a new manual finding in Splunk Enterprise Security / Mission Control (the ES 8.0+ term for what used to be a 'notable event'). | **required** `title`, `description`, `security_domain`, `entity`, `entity_type`, `finding_score`<br />optional `disposition`, `fields`, `owner`, `status`, `urgency` |
| `splunk_create_investigation` | Create a new investigation (case) in Splunk Enterprise Security via the Mission Control v2 REST API. | **required** `name`<br />optional `description`, `incident_origin`, `owner`, `sensitivity`, `status`, `urgency` |
| `splunk_create_saved_search` | Create a new saved search | **required** `name`, `search`<br />optional `cron_schedule`, `description`, `earliest_time`, `is_scheduled`, `latest_time` |
| `splunk_create_search_job` | Create a search job that runs asynchronously | **required** `query`<br />optional `earliest_time`, `latest_time`, `search_mode` |
| `splunk_delete_saved_search` | Delete an existing saved search by name | **required** `name`<br />optional `app`, `owner` |
| `splunk_export_results` | Export search results in a specific format | **required** `query`<br />optional `earliest_time`, `latest_time`, `max_results`, `output_mode` |
| `splunk_get_index` | Get details of a specific index | **required** `name` |
| `splunk_get_investigation` | Retrieve full details of a specific investigation (case) by ID from Splunk Enterprise Security, including status, description, collaborators, tags, and timestamps. | **required** `investigation_id` |
| `splunk_get_job_results` | Retrieve results from a completed search job | **required** `sid`<br />optional `count`, `offset`, `output_mode` |
| `splunk_get_job_status` | Get the status and progress of a search job | **required** `sid` |
| `splunk_get_saved_search` | Get details of a specific saved search | **required** `name`<br />optional `app`, `owner` |
| `splunk_get_server_info` | Get Splunk server information and status | — |
| `splunk_link_findings_to_investigation` | Link existing Mission Control v2 findings to an investigation in a single bulk request (POST /investigations/{guid}/findings). | **required** `investigation_id`, `finding_ids`<br />optional `finding_times` |
| `splunk_list_findings` | List Splunk ES findings via Mission Control v2 (GET /findings). | optional `count`, `earliest`, `latest`, `offset` |
| `splunk_list_indexes` | List all indexes accessible to the user | optional `count`, `datatype`, `offset` |
| `splunk_list_investigations` | List investigations (cases) from Splunk ES Mission Control v2. | optional `count`, `disposition`, `earliest`, `latest`, `offset`, `owner`, `sensitivity`, `status`, `urgency` |
| `splunk_list_jobs` | List all search jobs for the current user | optional `count`, `offset`, `sort_dir`, `sort_key` |
| `splunk_list_saved_searches` | List all saved searches accessible to the user | optional `app`, `count`, `offset`, `owner` |
| `splunk_notable_update` | **[Legacy — do not use for structured updates on ES 8.x]** On Splunk Enterprise Security 8.x, status / owner / urgency / disposition updates through this tool **silently no-op** even when the endpoint returns 2xx. | optional `app`, `comment`, `disposition`, `new_owner`, `owner`, `rule_uids`, `search_id`, `status_id`, `urgency` |
| `splunk_run_saved_search` | Dispatch a saved search and return the job SID for tracking | **required** `name`<br />optional `app`, `earliest_time`, `latest_time`, `owner`, `trigger_actions` |
| `splunk_run_search` | Execute a Splunk search query and return results | **required** `query`<br />optional `earliest_time`, `latest_time`, `max_results`, `output_mode` |
| `splunk_update_finding` | [PRIMARY tool for finding status / owner / urgency / disposition updates on Splunk ES 8.x] Use this instead of `notable_update` whenever the user asks to change a finding's status, owner, urgency or disposition. | **required** `finding_id`<br />optional `disposition`, `notable_time`, `owner`, `status`, `urgency` |
| `splunk_update_investigation` | Partially update an investigation (case) in Splunk ES Mission Control v2. Only the provided fields are sent to the server; unspecified fields are left untouched. | **required** `investigation_id`<br />optional `description`, `disposition`, `name`, `owner`, `sensitivity`, `status`, `urgency` |
| `splunk_update_saved_search` | Update an existing saved search | **required** `name`<br />optional `app`, `cron_schedule`, `description`, `disabled`, `is_scheduled`, `owner`, `search` |

## Sumo Logic

12 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `sumo-logic_cloud_siem_add_comment_to_insight` | Add a comment to a Cloud SIEM Insight for collaboration. | **required** `insightId`, `comment` |
| `sumo-logic_cloud_siem_add_tags_to_insight` | Add tags to a Cloud SIEM Insight for better organization. | **required** `insightId`, `tagName` |
| `sumo-logic_cloud_siem_enrich_entities` | Enrich entity information with additional context from Cloud SIEM. | **required** `entityType`, `entityValue` |
| `sumo-logic_cloud_siem_get_entity_details` | Get detailed information about a specific Cloud SIEM Entity (user, hostname, IP address, etc.) by ID. | **required** `id`<br />optional `expand` |
| `sumo-logic_cloud_siem_get_insight_details` | Get detailed information about a specific Cloud SIEM Insight by ID. | **required** `id`, `recordSummaryFields`<br />optional `exclude` |
| `sumo-logic_cloud_siem_list_insights` | Get a list of Cloud SIEM Insights with optional filtering. Note: This API will not return more than 10,000 Insights for a given query. Use the query parameter to filter results. | **required** `recordSummaryFields`<br />optional `exclude`, `limit`, `offset`, `q` |
| `sumo-logic_cloud_siem_ping` | Test connectivity to Sumo Logic Cloud SIEM. | — |
| `sumo-logic_cloud_siem_search_entity_signals` | Search for signals related to a specific entity in Cloud SIEM. | **required** `entityValue`<br />optional `endTime`, `limit`, `minSeverity`, `offset`, `startTime` |
| `sumo-logic_cloud_siem_update_insight_assignee` | Assign or reassign a Cloud SIEM Insight to a specific user or team. | **required** `insightId`, `assigneeType`, `assigneeValue` |
| `sumo-logic_cloud_siem_update_insight_status` | Update the status of a Cloud SIEM Insight. When closing an insight you must also provide a resolution; omit the resolution for any other status. | **required** `insightId`, `status`<br />optional `resolution` |
| `sumo-logic_query_metrics` | Query metrics data from Sumo Logic. | **required** `query`, `from`, `to` |
| `sumo-logic_search_logs` | Search logs in Sumo Logic with a custom query. Results are limited to prevent overwhelming responses. | **required** `query`, `from`, `to`<br />optional `limit` |

## Swimlane

18 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `swimlane_create_comment` | Add a comment or investigation note to a Swimlane record | **required** `app_id`, `record_id`, `message` |
| `swimlane_create_record` | Create a new record in a Swimlane application using human-readable field names | **required** `app_id`, `values` |
| `swimlane_delete_record` | Delete a record from a Swimlane application by ID | **required** `app_id`, `record_id` |
| `swimlane_execute_task` | Trigger a Swimlane orchestration task to run immediately (e.g., enrichment, response action) | **required** `task_id` |
| `swimlane_find_record_by_field` | Find records in a Swimlane application whose named field matches a value (e.g. find the record where 'Client Name' is 'Acme'). | **required** `app_id`, `field_name`, `value`<br />optional `limit` |
| `swimlane_get_app` | Get a single Swimlane application by id, name, or acronym, including its full field schema (the UI layout tree is omitted for size). | **required** `query` |
| `swimlane_get_group` | Get a single Swimlane group by ID or name | **required** `query` |
| `swimlane_get_record` | Get a single Swimlane record by record_id OR tracking_id (e.g. 'INC-42'), never both. app_id must be the application's internal id — resolve a name or acronym with get_app first. | **required** `app_id`<br />optional `record_id`, `tracking_id` |
| `swimlane_get_task` | Get an orchestration task (automation step) by ID, including status and metadata | **required** `task_id` |
| `swimlane_get_user` | Get a single Swimlane user by display name or username. Use swimlane_search_users to discover users first, then look up by their displayName or userName. Swimlane user IDs cannot be used for direct lookup. | **required** `query` |
| `swimlane_get_workflow` | Get a Swimlane workflow/playbook definition by ID (read-only, for triage context). Requires application admin permissions — the personal access token must belong to a user with the Administration role on the workflow's parent application. | **required** `workflow_id` |
| `swimlane_list_apps` | List Swimlane applications (form definitions) as compact summaries: id, name, acronym, description, field count, dates. Use get_app for one app's full field schema — the summaries deliberately omit it. | optional `cursor`, `limit` |
| `swimlane_list_attachments` | List file attachment metadata on a Swimlane record (no file content) | **required** `app_id`, `record_id` |
| `swimlane_list_comments` | List comments and investigation notes on a Swimlane record | **required** `app_id`, `record_id` |
| `swimlane_list_groups` | List all Swimlane user groups | — |
| `swimlane_list_records` | List records in a Swimlane application with field names resolved to human-readable labels | **required** `app_id`<br />optional `limit` |
| `swimlane_search_users` | Search Swimlane users by display name. Provide a partial name to search (e.g. 'admin'). Wildcards like '*' are not supported. To list all users, pass an empty string. | **required** `query` |
| `swimlane_update_record` | Update fields on an existing Swimlane record using human-readable field names. | **required** `app_id`, `values`<br />optional `record_id`, `tracking_id` |

## ThreatConnect

24 tools. Available as 2 connections: ThreatConnect (API key), ThreatConnect (HMAC) (credentials in connection settings).

| Tool | Description | Arguments |
| --- | --- | --- |
| `threatconnect_create_association` | Create an association between two ThreatConnect objects. Links indicators to groups, groups to cases, indicators to cases, etc. Source and target types can be: indicators, groups, or cases. | **required** `source_type`, `source_id`, `target_type`, `target_id`<br />optional `owner` |
| `threatconnect_create_case` | Create a new incident response case with name, status (Open/Closed), severity (Low/Medium/High/Critical), and optional assignee. | **required** `name`, `status`, `severity`<br />optional `assignee`, `description`, `tags` |
| `threatconnect_create_group` | Create a new group (Incident, Adversary, Campaign, Threat, Malware, Document, Report, etc.) with optional tags and status. | **required** `group_type`, `name`<br />optional `event_date`, `owner`, `status`, `tags` |
| `threatconnect_create_indicator` | Create a new threat indicator. Supports Address (IP), Host (domain), File (hash), URL, EmailAddress, ASN, CIDR, Mutex, and more. Set confidence (0-100) and rating (1.0-5.0) for threat scoring. | **required** `indicator_type`<br />optional `active`, `address`, `confidence`, `host_name`, `ip`, `md5`, `owner`, `rating`, `sha1`, `sha256`, `summary`, `tags`, `text` |
| `threatconnect_create_tag` | Create a new tag for organizing indicators, groups, and cases. | **required** `name` |
| `threatconnect_create_task` | Create a new task within a case. Specify case ID, name, and optionally an assignee, due date, and status. | **required** `name`, `case_id`<br />optional `assignee`, `description`, `due_date`, `status` |
| `threatconnect_delete_group` | Delete a group by ID. | **required** `group_id` |
| `threatconnect_delete_indicator` | Delete a threat indicator by numeric ID or summary value. | **required** `indicator_id`<br />optional `owner` |
| `threatconnect_get_case` | Get a single case by ID with full details including tasks, artifacts, and notes. | **required** `case_id`<br />optional `fields` |
| `threatconnect_get_group` | Get a single group by ID with full details including associations, tags, and attributes. | **required** `group_id`<br />optional `fields` |
| `threatconnect_get_indicator` | Get a single indicator by numeric ID or summary value (IP address, hostname, file hash, URL, email address). | **required** `indicator_id`<br />optional `fields`, `owner` |
| `threatconnect_get_victim` | Get a single victim by ID with details including assets and associations. | **required** `victim_id`<br />optional `fields` |
| `threatconnect_list_cases` | List incident response cases with optional TQL filtering by status, severity, assignee, and date range. | optional `fields`, `owner`, `result_limit`, `result_start`, `tql` |
| `threatconnect_list_groups` | List threat intelligence groups (Incidents, Adversaries, Campaigns, Threats, Malware, etc.) with optional TQL filtering. | optional `fields`, `group_type`, `owner`, `result_limit`, `result_start`, `tql` |
| `threatconnect_list_indicators` | List threat indicators (IOCs) with optional TQL filtering. Supports filtering by type (Address, Host, File, URL, etc.), rating, confidence, date range, and owner. | optional `fields`, `indicator_type`, `owner`, `result_limit`, `result_start`, `tql` |
| `threatconnect_list_owners` | List accessible organizations and communities (owners). Owners represent data partitions for threat intelligence sharing. | optional `result_limit`, `result_start` |
| `threatconnect_list_security_labels` | List security labels (e.g., TLP:RED, TLP:GREEN) used for classification and access control. | optional `owner`, `result_limit`, `result_start`, `tql` |
| `threatconnect_list_tags` | List tags with optional TQL filtering and owner scoping. | optional `owner`, `result_limit`, `result_start`, `tql` |
| `threatconnect_list_tasks` | List tasks with optional TQL filtering by case, status, and assignee. | optional `owner`, `result_limit`, `result_start`, `tql` |
| `threatconnect_list_victims` | List victims with optional TQL filtering. Victims represent targeted entities (people, organizations) in threat scenarios. | optional `fields`, `owner`, `result_limit`, `result_start`, `tql` |
| `threatconnect_update_case` | Update an existing case's status, severity, resolution, assignee, description, or tags. | **required** `case_id`<br />optional `assignee`, `description`, `name`, `resolution`, `severity`, `status`, `tags` |
| `threatconnect_update_group` | Update an existing group's name, status, or tags. | **required** `group_id`<br />optional `name`, `status`, `tags` |
| `threatconnect_update_indicator` | Update an existing indicator's confidence, rating, active status, or tags. Identify the indicator by numeric ID or summary value. | **required** `indicator_id`<br />optional `active`, `confidence`, `owner`, `rating`, `tags` |
| `threatconnect_update_task` | Update a task's name, status, assignee, due date, or description. | **required** `task_id`<br />optional `assignee`, `description`, `due_date`, `name`, `status` |

## Trellix Endpoint Security (HX)

13 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `trellix-hx_get_alert` | Get full details for a specific Trellix HX alert by numeric ID. Returns the matched indicator, condition, event type, event values (process command lines, file hashes, network connections), timestamps, and resolution status. | **required** `alert_id` |
| `trellix-hx_get_alert_group` | Get details for a specific Trellix HX alert group (correlated incident). Returns the assessment summary, source, first/last event timestamps, acknowledgement status, and event statistics. Required role: api_analyst. | **required** `group_id` |
| `trellix-hx_get_host` | Get full details for a specific Trellix HX managed endpoint by agent ID. Returns OS information, agent version, check-in timestamps, containment state, and alert statistics. Required role: api_analyst. | **required** `agent_id` |
| `trellix-hx_get_host_containment` | Get the containment status and history for a specific Trellix HX host. Returns state (normal/contain/containing/releasing/contain_fail/release_fail), timestamps, requesting actor, and containing actor. Required role: api_analyst. | **required** `agent_id` |
| `trellix-hx_get_indicator` | Get details for a specific Trellix HX indicator (IOC), optionally including match conditions (file hashes, registry keys, network IOCs, process names, etc.) when include_conditions=true (the default). | **required** `category_uri_name`, `indicator_uri_name`<br />optional `include_conditions` |
| `trellix-hx_get_search_results` | Retrieve match results (hits) from a Trellix HX enterprise search. | **required** `search_id`<br />optional `limit`, `offset` |
| `trellix-hx_list_alert_groups` | List correlated alert groups (incidents) in Trellix HX. Alert groups correlate multiple related raw alerts into a single incident with an assessment summary. | optional `limit`, `offset` |
| `trellix-hx_list_alerts` | List security alerts from Trellix HX with optional filtering. Returns alert ID, matched indicator, event type, timestamps, source, resolution status, and event values (command lines, file hashes, etc.). | optional `host_id`, `limit`, `offset`, `reported_after`, `resolution`, `source` |
| `trellix-hx_list_file_acquisitions` | List file acquisition jobs in Trellix HX. File acquisitions collect specific files from endpoints for forensic analysis. Returns acquisition ID, requested file path and name, state, MD5 hash, and associated host. | optional `host_id`, `limit`, `offset` |
| `trellix-hx_list_hosts` | List managed endpoint hosts in Trellix HX with optional filtering. Returns agent ID, hostname, IP address, OS, agent version, containment state, last check-in timestamps, and alert counts. Required role: api_analyst. | optional `containment_state`, `has_active_threats`, `has_alerts`, `hostname`, `ip_address`, `limit`, `offset`, `os_platform`, `search` |
| `trellix-hx_list_indicators` | List threat indicators (IOCs) configured in the Trellix HX appliance. Returns indicator ID, name, category, platforms, active-since date, and statistics (alerted agents, active conditions). Required role: api_analyst. | optional `category`, `has_alerts`, `limit`, `offset`, `search_term` |
| `trellix-hx_list_searches` | List enterprise IOC sweep searches in Trellix HX. Enterprise searches perform asynchronous IOC sweeps across host sets. Returns search ID, state (RUNNING/COMPLETE/STOPPED/FAILED), host set, creation actor, and settings. | optional `host_set_id`, `limit`, `offset`, `state` |
| `trellix-hx_list_triage_acquisitions` | List triage acquisition jobs in Trellix HX. Triage acquisitions collect endpoint triage packages for forensic analysis. Returns acquisition ID, state, host, request actor, timestamps, and any associated indicator. | optional `host_id`, `limit`, `offset`, `state` |

## Vectra AI

23 tools. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `vectra-ai_create_assignment` | Create new assignment. | **required** `assignment_data` |
| `vectra-ai_create_entity_note` | Add an investigation note to an entity (host or account). Returns: str: Confirmation message with note details. | **required** `entity_id`, `entity_type`, `note` |
| `vectra-ai_delete_assignment` | Get specific assignment by ID. | **required** `assignment_id` |
| `vectra-ai_get_account_details` | Get complete detailed information about a specific account entity. This tool returns account details including detections, scoring information, associated accounts, access history, detection summaries, external data, and more. | **required** `account_id`<br />optional `exclude_fields`, `fields`, `include_access_history`, `include_detection_summaries`, `include_external`, `src_linked_account` |
| `vectra-ai_get_assignment_detail_by_id` | Retrieve details of a specific investigation assignment. Returns: str: JSON string with details of the assignment. Raises: Exception: If fetching assignment details fails. | **required** `assignment_id` |
| `vectra-ai_get_assignment_for_entity` | Retrieve investigation assignment for a specific account. Returns: str: JSON string with assignment details for the account. Raises: Exception: If fetching assignment fails. | **required** `entity_ids`, `entity_type` |
| `vectra-ai_get_detection_count` | Get the total count of detections matching the specified criteria. Returns: str: Count of detections matching the criteria. | optional `detection_category`, `detection_name`, `end_date`, `is_targeting_key_asset`, `src_ip`, `start_date`, `state` |
| `vectra-ai_get_detection_details` | Get complete detailed information for a particular detection. Returns: str: JSON string with detection details. Raises: Exception: If fetching detection details fails. | **required** `detection_id` |
| `vectra-ai_get_detection_pcap` | Get Vectra Match statistics. | **required** `detection_id` |
| `vectra-ai_get_detection_summary` | Get a concise summary of a detection including its ID, name, category, last timestamp, triage status, state, entity type, and detection summary. | **required** `detection_id` |
| `vectra-ai_get_host_details` | Get complete detailed information about a specific host entity. Returns: str: Formatted string with detailed information about the host entity. | **required** `host_id` |
| `vectra-ai_list_assignments` | List all investigation assignments with optional filtering by timestamp and resolved state. Returns: str: JSON string with list of assignments. | optional `created_after`, `resolved` |
| `vectra-ai_list_assignments_for_user` | List all investigation assignments assigned to a user/analyst. Returns: str: JSON string with list of assignments. | **required** `user_id`<br />optional `resolved` |
| `vectra-ai_list_detection_ids` | List detection IDs with filtering and sorting options. Use this to get a list of detection IDs based on various criteria. Returns: str: JSON string with list of detection IDs. | optional `detection_category`, `detection_name`, `end_date`, `is_targeting_key_asset`, `limit`, `ordering`, `src_ip`, `start_date`, `state` |
| `vectra-ai_list_detections_with_basic_info` | List detections with basic information and filtering options. Use this to get a quick overview of detections without detailed information. Returns: str: JSON string with list of detections ids. | optional `detection_category`, `detection_name`, `end_date`, `is_targeting_key_asset`, `limit`, `ordering`, `src_ip`, `start_date`, `state` |
| `vectra-ai_list_detections_with_details` | List detections with filtering and sorting options. Use this to get a detailed list of detections based on various criteria. Returns: str: JSON string with list of detections. | optional `detection_category`, `detection_name`, `end_date`, `is_targeting_key_asset`, `limit`, `ordering`, `src_ip`, `start_date`, `state` |
| `vectra-ai_list_entities` | List entities (hosts & accounts) in Vectra platform based on various filters. This tool returns entities with all their detailed information. Returns: str: Formatted string with list of detections. | **required** `entity_type`<br />optional `host_ip`, `is_prioritized`, `limit`, `name`, `ordering`, `state`, `tags` |
| `vectra-ai_list_entity_detections` | List all detections with full details for a specific entity. Returns: str: JSON string with list of detections for the entity. | **required** `entity_id`<br />optional `state` |
| `vectra-ai_list_lockdown_entities` | List entities that are currently in lockdown. Returns: str: JSON string with list of entities in lockdown. | — |
| `vectra-ai_list_platform_users` | List users in the Vectra platform. Returns: str: JSON string with list of users. | optional `email`, `last_login_after`, `limit`, `role` |
| `vectra-ai_lookup_entity_info_by_name` | Retrieve information about an entity (account or host) by its name. Search is case-insensitive and can match partial names. | **required** `entity_name` |
| `vectra-ai_lookup_host_by_ip` | Retrieve information about a host entity by its IP address. Returns: str: Formatted string with host information including name, ID, type, last detection timestamp, prioritization status, urgency score, state, and IP address. | **required** `host_ip` |
| `vectra-ai_mark_detection_fixed` | Marks or unmark detection as fixed. | **required** `detection_ids`, `fixed_status` |

## VirusTotal

7 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `virustotal_get_analysis` | Retrieve the status and results of a VirusTotal analysis by its id (returned by submit_url_scan or reanalyse_file). The attributes.status field is 'queued', 'in-progress', or 'completed'. The meta field identifies the scanned file or URL. | **required** `analysis_id` |
| `virustotal_get_domain_report` | Get the VirusTotal report for a domain. Returns detection stats, reputation, WHOIS, DNS records, categories, and related certificates. | **required** `domain` |
| `virustotal_get_file_report` | Get the VirusTotal analysis report for a file by its hash (MD5, SHA-1, or SHA-256). Returns antivirus detection stats, engine results, reputation, file metadata, and relationships. | **required** `file_hash` |
| `virustotal_get_ip_report` | Get the VirusTotal report for an IPv4 or IPv6 address. Returns detection stats, reputation, ASN/owner, country, and related certificates. | **required** `ip_address` |
| `virustotal_get_url_report` | Get the VirusTotal analysis report for a URL. Returns detection stats, engine verdicts, categories, and reputation. Raises a not-found error if the URL has never been submitted; use submit_url_scan first to analyse a new URL. | **required** `url` |
| `virustotal_reanalyse_file` | Request a fresh VirusTotal analysis of a file already present in the dataset, identified by its hash (MD5/SHA-1/SHA-256). Returns an analysis object whose id can be polled with get_analysis to retrieve updated detection results. | **required** `file_hash` |
| `virustotal_submit_url_scan` | Submit a URL to VirusTotal for scanning. Returns an analysis object whose id can be polled with get_analysis to retrieve the results once the scan completes. | **required** `url` |

## Wazuh

45 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `wazuh_assign_agent_to_group` | Add an agent to a group. An agent can belong to multiple groups. | **required** `group_id`, `agent_id` |
| `wazuh_clear_syscheck_results` | Clear all stored FIM results for an agent. The next scan will start fresh. | **required** `agent_id` |
| `wazuh_create_group` | Create a new agent group in the Wazuh manager. | **required** `group_id` |
| `wazuh_delete_agent` | Delete a single Wazuh agent by its ID. Refuses wildcard / multi-ID input. | **required** `agent_id`<br />optional `purge` |
| `wazuh_get_agent` | Get detailed information about a specific Wazuh agent by its ID (zero-padded string, e.g., '001'). | **required** `agent_id` |
| `wazuh_get_agent_config` | Get the active configuration of a specific component on a Wazuh agent. | **required** `agent_id`, `component`, `configuration` |
| `wazuh_get_agent_stats` | Get statistical information from a Wazuh agent daemon. | **required** `agent_id`<br />optional `component` |
| `wazuh_get_agent_summary` | Get a summary of agent counts grouped by connection status (active, disconnected, never_connected, pending, total). | — |
| `wazuh_get_cdb_list` | Get the contents of a specific CDB list file via `GET /lists/files/{filename}`. Returns the file's key/value entries — use `list_cdb_lists` for the metadata listing across all CDB list files. | **required** `filename` |
| `wazuh_get_cluster_health` | Get a health check of the Wazuh cluster, showing node connectivity and sync status. | — |
| `wazuh_get_cluster_status` | Get Wazuh cluster status (enabled/disabled, running/stopped). | — |
| `wazuh_get_decoder` | Get details of a specific Wazuh decoder by name. | **required** `decoder_name` |
| `wazuh_get_group_agents` | List all agents that belong to a specific group. | **required** `group_id`<br />optional `limit`, `offset` |
| `wazuh_get_manager_info` | Get Wazuh manager version, compilation date, and installation path. | — |
| `wazuh_get_manager_logs` | Get recent Wazuh manager log messages for troubleshooting. | optional `level`, `limit`, `offset`, `q`, `sort`, `tag` |
| `wazuh_get_manager_stats` | Get Wazuh manager daemon statistics (events processed, alerts generated). | — |
| `wazuh_get_manager_status` | Get the status of all Wazuh manager daemons (running/stopped). | — |
| `wazuh_get_rule` | Get details of a specific Wazuh rule by its numeric ID. | **required** `rule_id` |
| `wazuh_get_sca_checks` | Get detailed SCA check results for a specific policy on an agent, showing pass/fail status for each check. | **required** `agent_id`, `policy_id`<br />optional `limit`, `offset`, `q`, `result` |
| `wazuh_get_sca_summary` | Get a high-level SCA compliance summary for an agent. Returns the list of evaluated policies with their pass/fail/score totals — same endpoint as list_sca_policies, provided as an alias for discoverability. | **required** `agent_id` |
| `wazuh_get_syscollector_hardware` | Get hardware inventory information for an agent (CPU, RAM, board serial). | **required** `agent_id` |
| `wazuh_get_syscollector_os` | Get operating system information for an agent (OS name, version, architecture). | **required** `agent_id` |
| `wazuh_list_agents` | List Wazuh agents with optional filtering by status, OS, group, or WQL query. Returns agent ID, name, IP, status, OS info, and group membership. | optional `group`, `limit`, `offset`, `q`, `search`, `sort`, `status` |
| `wazuh_list_cdb_lists` | List CDB (Constant Database) lists used for threat intelligence lookups in rules. | optional `filename`, `limit`, `offset`, `search`, `sort` |
| `wazuh_list_cluster_nodes` | List all nodes in the Wazuh cluster with their status and type (master/worker). | optional `limit`, `offset`, `search`, `sort` |
| `wazuh_list_decoder_files` | List all decoder files loaded in the Wazuh manager. | optional `limit`, `offset`, `search`, `sort` |
| `wazuh_list_decoders` | List Wazuh decoders with optional filtering by filename or status. | optional `filename`, `limit`, `offset`, `q`, `search`, `sort`, `status` |
| `wazuh_list_groups` | List all agent groups configured in the Wazuh manager. | optional `limit`, `offset`, `search`, `sort` |
| `wazuh_list_mitre_tactics` | List MITRE ATT&CK tactics known to the Wazuh manager. | optional `limit`, `offset`, `q`, `search`, `sort` |
| `wazuh_list_mitre_techniques` | List MITRE ATT&CK techniques known to the Wazuh manager, useful for mapping alerts to the MITRE framework. | optional `limit`, `offset`, `q`, `search`, `sort` |
| `wazuh_list_rule_files` | List all rule files loaded in the Wazuh manager. | optional `limit`, `offset`, `search`, `sort` |
| `wazuh_list_rule_groups` | List all available rule groups in the Wazuh manager. | optional `limit`, `offset`, `search`, `sort` |
| `wazuh_list_rules` | List Wazuh rules with optional filtering by level, group, filename, or status. | optional `filename`, `group`, `level`, `limit`, `offset`, `q`, `search`, `sort`, `status` |
| `wazuh_list_sca_policies` | List Security Configuration Assessment (SCA) policies evaluated on an agent, showing compliance scores. | **required** `agent_id` |
| `wazuh_list_syscheck_results` | Get File Integrity Monitoring (FIM) scan results for an agent, showing file changes detected. | **required** `agent_id`<br />optional `event_type`, `file`, `limit`, `offset`, `q`, `search`, `sort` |
| `wazuh_list_syscollector_packages` | List installed packages/software on an agent with optional filtering. | **required** `agent_id`<br />optional `limit`, `offset`, `q`, `search`, `sort` |
| `wazuh_list_syscollector_ports` | List open network ports on an agent. | **required** `agent_id`<br />optional `limit`, `offset`, `q`, `sort` |
| `wazuh_list_syscollector_processes` | List running processes on an agent. | **required** `agent_id`<br />optional `limit`, `offset`, `q`, `search`, `sort` |
| `wazuh_remove_agent_from_group` | Remove an agent from a specific group. | **required** `group_id`, `agent_id` |
| `wazuh_restart_agents` | Restart one or more Wazuh agents by their IDs. This forces agents to reload their configuration. | **required** `agents_list` |
| `wazuh_restart_manager` | Restart the Wazuh manager. This will briefly interrupt agent connections. | — |
| `wazuh_run_active_response` | Execute an active response command on one or more agents (e.g., block an IP, restart a service). | **required** `command`, `agents_list`<br />optional `alert`, `arguments` |
| `wazuh_run_logtest` | Test a log sample against the current rules and decoders. Useful for validating rule behavior before deployment. | **required** `event`, `log_format`<br />optional `location`, `token` |
| `wazuh_run_syscheck_scan` | Trigger a File Integrity Monitoring (FIM) scan on one or more agents. | **required** `agents_list` |
| `wazuh_upgrade_agents` | Upgrade one or more Wazuh agents to the latest available version. | **required** `agents_list` |

---

## Engineering and code

Source: https://docs.kindo.ai/reference/tool-catalog/engineering-code/

:::note[Beta]
The tool catalog is in beta and is a point-in-time snapshot of the integration inventory, so an entry can differ from what your organization sees in product.
:::

Source hosts, issue trackers, and developer platforms an agent can read and write. 10 integrations, 309 tools.

Tool names below are the fully qualified names an agent sees once the integration is connected. Where an integration offers more than one connection, the names shown use the primary connection's prefix; connecting through another variant prefixes its tools with that variant's own integration ID instead. See [Tool Catalog](/reference/tool-catalog/) for how tools are granted and named.

## Azure DevOps

14 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `azure-devops_create_repository` | Create a new Git repository in a project | **required** `project`, `name` |
| `azure-devops_create_work_item` | Create a work item in the specified project | **required** `project`, `type`, `fields` |
| `azure-devops_delete_repository` | Delete a repository by ID or name | **required** `project`, `repositoryId` |
| `azure-devops_delete_work_item` | Delete a work item by ID | **required** `id`<br />optional `destroy`, `project` |
| `azure-devops_get_feed_packages` | Get packages from a specific Azure DevOps feed | **required** `feedId`<br />optional `getTopPackageVersions`, `includeAllVersions`, `includeDescription`, `includeUrls`, `isListed`, `packageNameQuery`, `project`, `protocolType`, `skip`, `top` |
| `azure-devops_get_project` | Get details of a single project | **required** `project`<br />optional `includeCapabilities`, `includeHistory` |
| `azure-devops_get_repository` | Get a specific repository by name or ID | **required** `project`, `repositoryId` |
| `azure-devops_get_work_item` | Get a work item by ID. Set expand to "Relations" or "All" to include parent/child hierarchy links and other related work item references. | **required** `id`<br />optional `expand`, `project` |
| `azure-devops_get_work_item_with_children` | Get a work item along with its parent reference and direct child work items (one level deep, not recursive) via hierarchy relations | **required** `id`<br />optional `project` |
| `azure-devops_list_feeds` | List feeds in an Azure DevOps organization or project | optional `feedRole`, `includeDeletedUpstreams`, `includeUrls`, `project` |
| `azure-devops_list_projects` | List projects in an Azure DevOps organization | optional `skip`, `top` |
| `azure-devops_list_repositories` | List Git repositories in a project | **required** `project`<br />optional `includeLinks` |
| `azure-devops_query_work_items` | Run a WIQL query and return matching work item references. Use `top` to cap the number of results. | **required** `query`<br />optional `project`, `top` |
| `azure-devops_update_work_item` | Update a work item by ID | **required** `id`, `fields`<br />optional `project` |

## Bitbucket Cloud

15 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `bitbucket-mcp_create_branch` | Create a new branch from a commit hash or existing ref. | **required** `workspace`, `repo_slug`, `name`, `target` |
| `bitbucket-mcp_create_pull_request` | Create a pull request from a source branch to a destination branch. | **required** `workspace`, `repo_slug`, `title`, `source_branch`, `destination_branch`<br />optional `description` |
| `bitbucket-mcp_get_branch` | Get a single branch by name. | **required** `workspace`, `repo_slug`, `name` |
| `bitbucket-mcp_get_commit` | Get a single commit by its SHA. | **required** `workspace`, `repo_slug`, `commit` |
| `bitbucket-mcp_get_current_user` | Get the authenticated user. Useful as a connection / auth check. | — |
| `bitbucket-mcp_get_file_source` | Get the text contents of a file at a given ref. Defaults to the repository's main branch when no ref is given. | **required** `workspace`, `repo_slug`, `file_path`<br />optional `ref` |
| `bitbucket-mcp_get_pull_request` | Get details about a single pull request by its numeric id. | **required** `workspace`, `repo_slug`, `pull_request_id` |
| `bitbucket-mcp_get_pull_request_diff` | Get the unified diff text for a pull request. | **required** `workspace`, `repo_slug`, `pull_request_id` |
| `bitbucket-mcp_get_repository` | Get details about a single Bitbucket repository. | **required** `workspace`, `repo_slug` |
| `bitbucket-mcp_list_branches` | List branches in a repository. | **required** `workspace`, `repo_slug`<br />optional `limit`, `query` |
| `bitbucket-mcp_list_commits` | List commit history for a repository, optionally restricted to a branch or revision. | **required** `workspace`, `repo_slug`<br />optional `limit`, `revision` |
| `bitbucket-mcp_list_pull_request_comments` | List comments on a pull request. | **required** `workspace`, `repo_slug`, `pull_request_id`<br />optional `limit` |
| `bitbucket-mcp_list_pull_requests` | List pull requests for a repository, optionally filtered by state. Defaults to OPEN pull requests. | **required** `workspace`, `repo_slug`<br />optional `limit`, `query`, `state` |
| `bitbucket-mcp_list_repositories` | List repositories in a Bitbucket Cloud workspace. | **required** `workspace`<br />optional `limit`, `query`, `sort` |
| `bitbucket-mcp_merge_pull_request` | Merge a pull request. | **required** `workspace`, `repo_slug`, `pull_request_id`<br />optional `merge_strategy`, `message` |

## Confluence

32 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `confluence_add_page_label` | Add one or more labels to a Confluence page. | **required** `page_id`, `labels` |
| `confluence_create_blog_post` | Create a blog post in a Confluence space. Body must be in storage format (XHTML). | **required** `space_id`, `title`<br />optional `body`, `status` |
| `confluence_create_comment` | Add a footer comment to a Confluence page. Body must be in storage format (XHTML). | **required** `page_id`, `body` |
| `confluence_create_page` | Create a new page in a Confluence space. Body must be in storage format (XHTML); atlas_doc_format is not supported for writes. | **required** `space_id`, `title`<br />optional `body`, `parent_id`, `status` |
| `confluence_delete_blog_post` | Delete a Confluence blog post by ID | **required** `blog_post_id` |
| `confluence_delete_content_property` | Delete a custom property from a Confluence page | **required** `page_id`, `property_id` |
| `confluence_delete_page` | Delete (trash) a Confluence page by ID | **required** `page_id` |
| `confluence_get_blog_post` | Get a Confluence blog post by ID with optional body content | **required** `blog_post_id`<br />optional `body_format` |
| `confluence_get_current_user` | Get the currently authenticated Confluence user | — |
| `confluence_get_page` | Get a Confluence page by ID with optional body content in storage format | **required** `page_id`<br />optional `body_format`, `include_version` |
| `confluence_get_page_ancestors` | Get the ancestor chain (breadcrumb) of a Confluence page from top to bottom | **required** `page_id` |
| `confluence_get_page_children` | Get direct child pages of a Confluence page | **required** `page_id`<br />optional `cursor`, `limit` |
| `confluence_get_space` | Get Confluence space details by ID | **required** `space_id` |
| `confluence_get_task` | Get a Confluence task by ID | **required** `task_id` |
| `confluence_get_whiteboard` | Get a Confluence whiteboard by ID | **required** `whiteboard_id` |
| `confluence_list_blog_posts` | List blog posts with optional space and status filtering | optional `body_format`, `cursor`, `limit`, `space_id`, `status` |
| `confluence_list_content_properties` | List custom properties on a Confluence page | **required** `page_id`<br />optional `cursor`, `limit` |
| `confluence_list_inline_comments` | List inline comments on a Confluence page | **required** `page_id`<br />optional `body_format`, `cursor`, `limit` |
| `confluence_list_page_attachments` | List attachments on a Confluence page | **required** `page_id`<br />optional `cursor`, `limit` |
| `confluence_list_page_comments` | List footer comments on a Confluence page | **required** `page_id`<br />optional `body_format`, `cursor`, `limit` |
| `confluence_list_page_labels` | List labels on a Confluence page | **required** `page_id`<br />optional `cursor`, `limit` |
| `confluence_list_page_versions` | List version history for a Confluence page | **required** `page_id`<br />optional `cursor`, `limit` |
| `confluence_list_pages` | List pages in a Confluence space with filtering by status, title, labels, and sort order | optional `body_format`, `cursor`, `limit`, `sort`, `space_id`, `status`, `title` |
| `confluence_list_space_permissions` | List permission assignments for a Confluence space (read-only) | **required** `space_id`<br />optional `cursor`, `limit` |
| `confluence_list_spaces` | List Confluence spaces with filtering by type (global/personal) and status | optional `cursor`, `limit`, `sort`, `space_type`, `status` |
| `confluence_list_tasks` | List Confluence tasks with optional filtering by status, space, or page | optional `assigned_to`, `cursor`, `limit`, `page_id`, `space_id`, `status` |
| `confluence_list_whiteboards` | List whiteboards in a Confluence space | optional `cursor`, `limit`, `space_id` |
| `confluence_remove_page_label` | Remove a label from a Confluence page by label name | **required** `page_id`, `label_name` |
| `confluence_search_content` | Search Confluence content using CQL (Confluence Query Language). Examples: 'type=page AND space=DEV', 'text~"authentication" AND type=page'. Uses v1 API. | **required** `cql`<br />optional `include_body`, `limit`, `start` |
| `confluence_set_content_property` | Set or update a custom property on a Confluence page. Value must be a JSON object (max 32KB). | **required** `page_id`, `key`, `value` |
| `confluence_update_page` | Update an existing Confluence page title and/or body. Requires the current version number (get it from get_page). The version number must be incremented by 1. Body must be in storage format (XHTML). | **required** `page_id`, `title`, `version_number`<br />optional `body`, `status` |
| `confluence_update_task` | Update a Confluence task status (complete/incomplete) | **required** `task_id`, `status` |

## Confluence Data Center

15 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `confluence-data-center-api-key_add_labels` | Add up to 20 global labels to a page or blog post in one call. Labels are how content is grouped and found later — 'label = runbook' is a CQL predicate search_content accepts. Adding a label that is already present is a no-op. | **required** `content_id`, `labels` |
| `confluence-data-center-api-key_create_comment` | Add a footer comment to a page. The body is Confluence storage format (XHTML), e.g. '&lt;p>Looks good to me&lt;/p>'. Inline comments anchored to highlighted text cannot be created through the REST API — only read back via list_comments. | **required** `content_id`, `body` |
| `confluence-data-center-api-key_create_content` | Create a page or blog post in a space, optionally nested under a parent page. The body is Confluence storage format (XHTML), the same format get_content returns for body_format='storage' — plain paragraphs go in &lt;p> tags. | **required** `space_key`, `title`, `body`<br />optional `content_type`, `parent_id` |
| `confluence-data-center-api-key_delete_content` | Move a page or blog post to the trash. Trashed content is recoverable by a space administrator and stops appearing in list_content and search_content; it is not purged. | **required** `content_id` |
| `confluence-data-center-api-key_get_content` | Read one page or blog post by id. CONCISE returns metadata plus the ancestor chain (the path from the space homepage down to this page) and is enough to orient yourself. | **required** `content_id`<br />optional `body_format`, `response_format` |
| `confluence-data-center-api-key_get_content_children` | List the direct child pages of a page, one level down. | **required** `content_id`<br />optional `limit`, `start` |
| `confluence-data-center-api-key_get_current_user` | Identify the authenticated user, and confirm the connection works at all — this is the cheapest health probe. | — |
| `confluence-data-center-api-key_list_attachments` | List the files attached to a page, optionally narrowed by exact filename or media type (e.g. 'application/pdf'). | **required** `content_id`<br />optional `filename`, `limit`, `media_type`, `start` |
| `confluence-data-center-api-key_list_comments` | List comments on a page, optionally filtered by where they sit: 'footer' for the comment stream at the bottom, 'inline' for comments anchored to highlighted text, 'resolved' for inline comments already closed out. | **required** `content_id`<br />optional `limit`, `locations`, `start` |
| `confluence-data-center-api-key_list_content` | List pages or blog posts filtered by space, exact title and status — the cheap, predictable path for browsing a wiki. | optional `content_type`, `limit`, `space_key`, `start`, `status`, `title` |
| `confluence-data-center-api-key_list_content_versions` | List a page's version history newest-first — who changed it, when, and the change message they left. Use it to see how a page evolved or who to ask about it. minor_edit marks an edit the author flagged as trivial. | **required** `content_id`<br />optional `limit`, `start` |
| `confluence-data-center-api-key_list_spaces` | List the spaces on the instance, filtered by key, type and status. Spaces are addressed by key (e.g. 'DEV'), not by a numeric id, and that key is what list_content and CQL 'space = ' expect. Pass a single key to look one space up. | optional `limit`, `space_keys`, `space_type`, `start`, `status` |
| `confluence-data-center-api-key_remove_label` | Remove one label from a page or blog post by name. Names containing a slash are handled automatically. Removing a label that is not present succeeds without changing anything. | **required** `content_id`, `label` |
| `confluence-data-center-api-key_search_content` | Search a Confluence Data Center wiki with CQL — the expressive path, covering full-text match, labels, ancestors, date ranges and ordering (e.g. 'space = DEV AND label = runbook ORDER BY lastmodified DESC'). | **required** `cql`<br />optional `limit`, `start` |
| `confluence-data-center-api-key_update_content` | Update a page or blog post's title, body, or both. | **required** `content_id`, `version`<br />optional `body`, `content_type`, `title` |

## GitHub (User OAuth)

81 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `github_cancel_workflow_run` | Cancel a workflow run | **required** `owner`, `repo`, `run_id` |
| `github_check_pull_request_merged` | Check if a pull request has been merged | **required** `owner`, `repo`, `pull_number` |
| `github_close_issue` | Close a GitHub issue | **required** `owner`, `repo`, `issue_number`<br />optional `state_reason` |
| `github_compare_branches` | Compare two branches | **required** `owner`, `repo`, `basehead`<br />optional `page`, `per_page` |
| `github_create_branch` | Create a new branch | **required** `owner`, `repo`, `branch`, `sha` |
| `github_create_comment` | Create a comment on a GitHub issue | **required** `owner`, `repo`, `issue_number`, `body` |
| `github_create_git_blob` | Upload one file's content as a git blob and get back its blob_sha — step 1 of the atomic multi-file commit chain: create_git_blob per file, then create_git_tree -> create_git_commit -> update_git_ref. | **required** `owner`, `repo`<br />optional `content`, `source_url` |
| `github_create_git_commit` | Create a commit object pointing at a tree — step 3 of the atomic multi-file commit chain (after create_git_tree, before update_git_ref). parent_shas is normally one element: the branch head commit SHA (get_branch -> commit.sha). | **required** `owner`, `repo`, `message`, `tree_sha`, `parent_shas`<br />optional `author` |
| `github_create_git_tree` | Assemble a git tree from blob SHAs — step 2 of the atomic multi-file commit chain (after create_git_blob, before create_git_commit). | **required** `owner`, `repo`, `entries`<br />optional `base_tree` |
| `github_create_issue` | Create a new GitHub issue | **required** `owner`, `repo`, `title`<br />optional `assignees`, `body`, `labels`, `milestone` |
| `github_create_milestone` | Create a new milestone in a GitHub repository | **required** `owner`, `repo`, `title`<br />optional `description`, `due_on`, `state` |
| `github_create_or_update_file` | Create or update a file in a repository with inline content. Provide the COMPLETE file content exactly as it should appear in the repository. Do not truncate, summarize, or use placeholders like '// rest of file'. | **required** `owner`, `repo`, `path`, `message`, `content`<br />optional `branch` |
| `github_create_pull_request` | Create a pull request | **required** `owner`, `repo`, `title`, `head`, `base`<br />optional `body`, `draft`, `issue`, `maintainer_can_modify` |
| `github_create_pull_request_review` | Create a review on a pull request | **required** `owner`, `repo`, `pull_number`<br />optional `body`, `comments`, `event` |
| `github_create_webhook` | Create a new webhook for a repository | **required** `owner`, `repo`, `name`, `config`<br />optional `active`, `events` |
| `github_delete_artifact` | Delete a workflow run artifact | **required** `owner`, `repo`, `artifact_id` |
| `github_delete_branch` | Delete a branch | **required** `owner`, `repo`, `branch` |
| `github_delete_file` | Delete a file from a repository | **required** `owner`, `repo`, `path`, `message`, `sha`<br />optional `author`, `branch`, `committer` |
| `github_delete_webhook` | Delete a webhook | **required** `owner`, `repo`, `hook_id` |
| `github_dequeue_pull_request` | Remove a pull request from the merge queue | **required** `owner`, `repo`, `pull_number` |
| `github_disable_workflow` | Disable a workflow | **required** `owner`, `repo`, `workflow_id` |
| `github_download_artifact` | Download an artifact (returns signed download URL, expires in 60 seconds) | **required** `owner`, `repo`, `artifact_id`<br />optional `archive_format` |
| `github_download_tarball_archive` | Get download URL for a tarball archive of a repository. Returns a URL that must be used with a separate download tool to actually fetch the file. | **required** `owner`, `repo`, `ref` |
| `github_download_zipball_archive` | Get download URL for a zipball archive of a repository. Returns a URL that must be used with a separate download tool to actually fetch the file. | **required** `owner`, `repo`, `ref` |
| `github_enable_workflow` | Enable a workflow | **required** `owner`, `repo`, `workflow_id` |
| `github_enqueue_pull_request` | Add a pull request to the merge queue | **required** `owner`, `repo`, `pull_number` |
| `github_get_artifact` | Get information about a specific artifact | **required** `owner`, `repo`, `artifact_id` |
| `github_get_authenticated_user` | Retrieve details of the authenticated GitHub user | — |
| `github_get_branch` | Get a specific branch | **required** `owner`, `repo`, `branch` |
| `github_get_branch_protection` | Get branch protection rules | **required** `owner`, `repo`, `branch` |
| `github_get_dependabot_alert` | Retrieve a single Dependabot security alert by alert number. Requires the token's `security_events` scope (or `public_repo` for public repositories). | **required** `owner`, `repo`, `alert_number` |
| `github_get_file_metadata` | Get the metadata for a file in a repository, including download URL | **required** `owner`, `repo`, `path`<br />optional `ref` |
| `github_get_file_raw_content` | Get the raw content of a file | **required** `owner`, `repo`, `path`<br />optional `ref` |
| `github_get_file_sha` | Get the SHA of a file | **required** `owner`, `repo`, `path`<br />optional `ref` |
| `github_get_issue` | Retrieve a GitHub issue details by number | **required** `owner`, `repo`, `issue_number` |
| `github_get_issue_git_branch_name` | Get a suggested Git branch name for a GitHub issue | **required** `owner`, `repo`, `issue_number` |
| `github_get_milestone` | Retrieve details of a specific milestone in a GitHub repository | **required** `owner`, `repo`, `milestone_number` |
| `github_get_pull_request` | Get a specific pull request | **required** `owner`, `repo`, `pull_number` |
| `github_get_pull_request_conflict_status` | Detect whether a pull request has merge conflicts with its base branch. Read-only. Returns: number, state, merged, mergeable, mergeable_state, conflict_status, has_conflicts, head (ref/sha), and base (ref/sha). | **required** `owner`, `repo`, `pull_number` |
| `github_get_pull_request_editability` | Return the merge/editability signals an agent needs to plan a PR update. | **required** `owner`, `repo`, `pull_number` |
| `github_get_repository` | Retrieve details of a specific GitHub repository | **required** `owner`, `repo` |
| `github_get_user` | Retrieve details of a specific GitHub user | **required** `username` |
| `github_get_webhook` | Get details of a specific webhook | **required** `owner`, `repo`, `hook_id` |
| `github_get_workflow` | Get a specific workflow | **required** `owner`, `repo`, `workflow_id` |
| `github_get_workflow_job` | Get a specific job from a workflow run | **required** `owner`, `repo`, `job_id` |
| `github_get_workflow_job_logs` | Get a signed download URL for the logs of a specific job (URL expires in 60 seconds) | **required** `owner`, `repo`, `job_id` |
| `github_get_workflow_run` | Get a specific workflow run | **required** `owner`, `repo`, `run_id` |
| `github_get_workflow_run_logs` | Get a signed download URL for the logs of a workflow run (URL expires in 60 seconds) | **required** `owner`, `repo`, `run_id` |
| `github_list_branches` | List branches in a repository | **required** `owner`, `repo`<br />optional `page`, `per_page`, `protected` |
| `github_list_collaborators` | List collaborators for a GitHub repository | **required** `owner`, `repo`<br />optional `affiliation`, `page`, `per_page` |
| `github_list_comments` | Retrieve comments for a GitHub issue | **required** `owner`, `repo`, `issue_number`<br />optional `page`, `per_page`, `since` |
| `github_list_dependabot_alerts` | List Dependabot security alerts for a repository. Returns {alerts, page_info} where page_info carries next_cursor / prev_cursor (null when absent). | **required** `owner`, `repo`<br />optional `after`, `before`, `direction`, `ecosystem`, `manifest`, `package`, `per_page`, `scope`, `severity`, `sort`, `state` |
| `github_list_issues` | List issues in a GitHub repository | **required** `owner`, `repo`<br />optional `assignee`, `direction`, `labels`, `page`, `per_page`, `since`, `sort`, `state` |
| `github_list_issues_by_assignee` | List issues assigned to a specific user | **required** `assignee`<br />optional `direction`, `page`, `per_page`, `sort`, `state` |
| `github_list_labels` | List available labels in a GitHub repository | **required** `owner`, `repo`<br />optional `page`, `per_page` |
| `github_list_milestones` | List milestones in a GitHub repository | **required** `owner`, `repo`<br />optional `direction`, `page`, `per_page`, `sort`, `state` |
| `github_list_my_issues` | List issues for the authenticated user | optional `direction`, `issue_filter`, `labels`, `page`, `per_page`, `since`, `sort`, `state` |
| `github_list_pull_request_commits` | List commits on a pull request | **required** `owner`, `repo`, `pull_number`<br />optional `page`, `per_page` |
| `github_list_pull_request_files` | List files changed in a pull request | **required** `owner`, `repo`, `pull_number`<br />optional `page`, `per_page` |
| `github_list_pull_request_review_comments` | List comments for a pull request review | **required** `owner`, `repo`, `pull_number`, `review_id`<br />optional `page`, `per_page` |
| `github_list_pull_request_reviews` | List reviews on a pull request | **required** `owner`, `repo`, `pull_number`<br />optional `page`, `per_page` |
| `github_list_pull_requests` | List pull requests in a repository | **required** `owner`, `repo`<br />optional `base`, `direction`, `head`, `page`, `per_page`, `sort`, `state` |
| `github_list_repositories` | List repositories for the authenticated user | optional `direction`, `page`, `per_page`, `repo_type`, `sort` |
| `github_list_repository_contents` | Lists the contents of a directory in a repository. The response will be an array of objects, one object of metadata including download URL for each item in the directory. | **required** `owner`, `repo`<br />optional `path`, `ref` |
| `github_list_webhooks` | List webhooks for a repository | **required** `owner`, `repo`<br />optional `page`, `per_page` |
| `github_list_workflow_run_artifacts` | List artifacts for a workflow run | **required** `owner`, `repo`, `run_id`<br />optional `name`, `page`, `per_page` |
| `github_list_workflow_run_jobs` | List jobs for a workflow run | **required** `owner`, `repo`, `run_id`<br />optional `job_filter`, `page`, `per_page` |
| `github_list_workflow_runs` | List workflow runs for a repository | **required** `owner`, `repo`<br />optional `actor`, `branch`, `check_suite_id`, `created`, `event`, `exclude_pull_requests`, `head_sha`, `page`, `per_page`, `status` |
| `github_list_workflows` | List workflows in a repository | **required** `owner`, `repo`<br />optional `page`, `per_page` |
| `github_merge_branch` | Merge a branch | **required** `owner`, `repo`, `base`, `head`<br />optional `commit_message` |
| `github_merge_pull_request` | Merge a pull request | **required** `owner`, `repo`, `pull_number`<br />optional `commit_message`, `commit_title`, `merge_method`, `sha` |
| `github_rerun_failed_jobs` | Re-run only the failed jobs from a workflow run | **required** `owner`, `repo`, `run_id`<br />optional `enable_debug_logging` |
| `github_rerun_workflow_run` | Re-run an entire workflow run | **required** `owner`, `repo`, `run_id`<br />optional `enable_debug_logging` |
| `github_trigger_workflow_dispatch` | Trigger a workflow_dispatch event for a workflow on a given ref | **required** `owner`, `repo`, `workflow_id`, `ref`<br />optional `inputs` |
| `github_update_branch_protection` | Update branch protection rules | **required** `owner`, `repo`, `branch`<br />optional `enforce_admins`, `required_pull_request_reviews`, `required_status_checks`, `restrictions` |
| `github_update_git_ref` | Advance (fast-forward) a branch to a commit — step 4, the final step of the atomic multi-file commit chain. This is the only step that moves the branch, so all files in the tree land atomically in one commit. | **required** `owner`, `repo`, `branch`, `sha` |
| `github_update_issue` | Update an existing GitHub issue | **required** `owner`, `repo`, `issue_number`<br />optional `assignees`, `body`, `labels`, `milestone`, `state`, `title` |
| `github_update_milestone` | Update an existing milestone in a GitHub repository | **required** `owner`, `repo`, `milestone_number`<br />optional `description`, `due_on`, `state`, `title` |
| `github_update_pull_request` | Update a pull request | **required** `owner`, `repo`, `pull_number`<br />optional `base`, `body`, `maintainer_can_modify`, `state`, `title` |
| `github_update_pull_request_branch` | Update a pull request branch with the latest upstream changes | **required** `owner`, `repo`, `pull_number`<br />optional `expected_head_sha` |
| `github_upload_file` | Upload a file to a repository by reference — for binary files or any content too large to pass inline. Pass `source_url`: a short-lived signed download URL minted by the `mint_upload_url` tool. | **required** `owner`, `repo`, `path`, `message`, `source_url`<br />optional `branch` |

## GitLab

55 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `gitlab_close_issue` | Close an issue in a GitLab project | **required** `project_id`, `issue_iid` |
| `gitlab_compare_repository_versions` | Compare two branches, tags, or commits in a GitLab repository | **required** `project_id`, `from_ref`, `to`<br />optional `straight` |
| `gitlab_create_branch` | Create a new branch in a GitLab repository | **required** `project_id`, `branch_name`<br />optional `ref` |
| `gitlab_create_file` | Create a new file in a GitLab repository with inline text content. The content is passed inline and is text-only, so it is subject to the ~10KB message-layer limit — larger or binary content is silently truncated. | **required** `project_id`, `file_path`, `content`, `commit_message`<br />optional `author_email`, `author_name`, `branch` |
| `gitlab_create_issue` | Create a new issue in a GitLab project | **required** `project_id`, `title`<br />optional `assignee_ids`, `confidential`, `description`, `due_date`, `labels`, `milestone_id` |
| `gitlab_create_issue_comment` | Create a comment on a GitLab issue | **required** `project_id`, `issue_iid`, `body` |
| `gitlab_create_label` | Create a new label in a GitLab project | **required** `project_id`, `name`, `color` |
| `gitlab_create_merge_request` | Create a new merge request in a GitLab project | **required** `project_id`, `source_branch`, `target_branch`, `title`<br />optional `assignee_ids`, `description`, `draft`, `labels`, `milestone_id`, `remove_source_branch`, `reviewer_ids`, `squash` |
| `gitlab_create_merge_request_comment` | Create a comment on a GitLab merge request | **required** `project_id`, `merge_request_iid`, `body` |
| `gitlab_create_milestone` | Create a new milestone in a GitLab project | **required** `project_id`, `title` |
| `gitlab_create_project` | Create a new GitLab project | **required** `name`<br />optional `default_branch`, `description`, `initialize_with_readme`, `namespace_id`, `path`, `visibility` |
| `gitlab_create_webhook` | Create a new webhook in a GitLab project | **required** `project_id`, `url`<br />optional `deployment_events`, `enable_ssl_verification`, `issues_events`, `job_events`, `merge_requests_events`, `note_events`, `pipeline_events`, `push_events`, `push_events_branch_filter`, `releases_events`, `tag_push_events`, `token`, `wiki_page_events` |
| `gitlab_delete_file` | Delete a file from a GitLab repository | **required** `project_id`, `file_path`, `commit_message`<br />optional `author_email`, `author_name`, `branch` |
| `gitlab_delete_label` | Delete a label from a GitLab project | **required** `project_id`, `label_id` |
| `gitlab_delete_webhook` | Delete a webhook from a GitLab project | **required** `project_id`, `hook_id` |
| `gitlab_download_file_to_kindo_library` | Download a file from a GitLab repository and save it to Kindo's file library. Returns the file content ID that can be used to reference the file. | **required** `project_id`, `file_path`<br />optional `ref` |
| `gitlab_get_branch` | Get a specific branch from a GitLab repository | **required** `project_id`, `branch` |
| `gitlab_get_current_user` | Get the current authenticated user | — |
| `gitlab_get_issue` | Get a specific issue from a GitLab project | **required** `project_id`, `issue_iid` |
| `gitlab_get_label` | Get a specific label from a GitLab project | **required** `project_id`, `label_id` |
| `gitlab_get_merge_request` | Get a specific merge request from a GitLab project | **required** `project_id`, `merge_request_iid` |
| `gitlab_get_milestone` | Get a specific milestone from a GitLab project | **required** `project_id`, `milestone_id` |
| `gitlab_get_project` | Get a specific GitLab project | **required** `project_id` |
| `gitlab_get_repository_contributors` | Get the list of contributors to a GitLab repository | **required** `project_id`<br />optional `order_by`, `page`, `per_page`, `sort` |
| `gitlab_get_user` | Get a specific user by ID | **required** `user_id` |
| `gitlab_get_user_projects` | Get a user's projects | **required** `user_id`<br />optional `archived`, `order_by`, `owned`, `page`, `per_page`, `search`, `sort`, `starred`, `visibility` |
| `gitlab_get_user_status` | Get the status of a user | **required** `user_id` |
| `gitlab_get_webhook` | Get a specific webhook from a GitLab project | **required** `project_id`, `hook_id` |
| `gitlab_list_branches` | List branches in a GitLab repository | **required** `project_id`<br />optional `page`, `per_page`, `search` |
| `gitlab_list_issue_comments` | List comments on a GitLab issue | **required** `project_id`, `issue_iid`<br />optional `page`, `per_page`, `sort` |
| `gitlab_list_issues` | List issues in a GitLab project | **required** `project_id`<br />optional `assignee_username`, `created_after`, `labels`, `milestone`, `page`, `per_page`, `search`, `state`, `updated_after` |
| `gitlab_list_labels` | List labels in a GitLab project | **required** `project_id` |
| `gitlab_list_merge_request_comments` | List comments on a GitLab merge request | **required** `project_id`, `merge_request_iid`<br />optional `page`, `per_page`, `sort` |
| `gitlab_list_merge_requests` | List merge requests in a GitLab project | **required** `project_id`<br />optional `assignee_username`, `author_username`, `created_after`, `labels`, `milestone`, `page`, `per_page`, `search`, `source_branch`, `state`, `target_branch`, `updated_after` |
| `gitlab_list_milestones` | List milestones in a GitLab project | **required** `project_id` |
| `gitlab_list_my_issues` | List issues for the authenticated user (defaults to assigned issues; use scope parameter for other filters) | optional `created_after`, `labels`, `page`, `per_page`, `scope`, `search`, `state`, `updated_after` |
| `gitlab_list_my_merge_requests` | List merge requests for the authenticated user (defaults to assigned; use scope parameter for other filters) | optional `created_after`, `labels`, `page`, `per_page`, `scope`, `search`, `state`, `updated_after` |
| `gitlab_list_projects` | List projects in GitLab | optional `archived`, `membership`, `order_by`, `owned`, `page`, `per_page`, `search`, `sort`, `starred`, `visibility` |
| `gitlab_list_protected_branches` | List protected branches in a GitLab repository | **required** `project_id` |
| `gitlab_list_repository_files` | List files and directories in a GitLab repository | **required** `project_id`<br />optional `page`, `path`, `per_page`, `recursive`, `ref` |
| `gitlab_list_users` | List users in GitLab | optional `active`, `blocked`, `exclude_external`, `exclude_internal`, `external`, `order_by`, `page`, `per_page`, `search`, `sort`, `username` |
| `gitlab_list_webhooks` | List webhooks in a GitLab project | **required** `project_id` |
| `gitlab_merge_branches` | Create a merge request to merge one branch into another in a GitLab repository | **required** `project_id`, `source_branch`, `target_branch`<br />optional `merge_request_title` |
| `gitlab_merge_merge_request` | Merge a merge request in a GitLab project | **required** `project_id`, `merge_request_iid`<br />optional `merge_commit_message`, `merge_when_pipeline_succeeds`, `should_remove_source_branch`, `squash_commit_message` |
| `gitlab_protect_branch` | Protect a branch in a GitLab repository | **required** `project_id`, `branch`<br />optional `allow_force_push`, `code_owner_approval_required`, `merge_access_level`, `push_access_level`, `unprotect_access_level` |
| `gitlab_set_user_status` | Set the status of the current user | optional `availability`, `clear_status_after`, `emoji`, `message` |
| `gitlab_unprotect_branch` | Unprotect a branch in a GitLab repository | **required** `project_id`, `branch` |
| `gitlab_update_file` | Update file content in a GitLab repository with inline text content. The content is passed inline and is text-only, so it is subject to the ~10KB message-layer limit — larger or binary content is silently truncated. | **required** `project_id`, `file_path`, `content`, `commit_message`<br />optional `author_email`, `author_name`, `branch` |
| `gitlab_update_issue` | Update an existing issue in a GitLab project | **required** `project_id`, `issue_iid`<br />optional `assignee_ids`, `confidential`, `description`, `due_date`, `labels`, `milestone_id`, `state_event`, `title` |
| `gitlab_update_label` | Update an existing label in a GitLab project | **required** `project_id`, `label_id`<br />optional `color`, `description`, `name` |
| `gitlab_update_merge_request` | Update an existing merge request in a GitLab project | **required** `project_id`, `merge_request_iid`<br />optional `assignee_ids`, `description`, `draft`, `labels`, `milestone_id`, `remove_source_branch`, `reviewer_ids`, `squash`, `state_event`, `title` |
| `gitlab_update_milestone` | Update an existing milestone in a GitLab project | **required** `project_id`, `milestone_id`<br />optional `description`, `state_event`, `title` |
| `gitlab_update_project` | Update an existing GitLab project | **required** `project_id`<br />optional `default_branch`, `description`, `name`, `path`, `visibility` |
| `gitlab_update_webhook` | Update an existing webhook in a GitLab project | **required** `project_id`, `hook_id`<br />optional `deployment_events`, `enable_ssl_verification`, `issues_events`, `job_events`, `merge_requests_events`, `note_events`, `pipeline_events`, `push_events`, `push_events_branch_filter`, `releases_events`, `tag_push_events`, `token`, `url`, `wiki_page_events` |
| `gitlab_upload_file` | Create or update a file in a GitLab repository by reference — for binary files or any content too large to pass inline. Pass `source_url`: a short-lived signed download URL minted by the `mint_upload_url` tool. | **required** `project_id`, `file_path`, `source_url`, `commit_message`<br />optional `author_email`, `author_name`, `branch` |

## Hugging Face

12 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `huggingface_cancel_job` | Cancel a running Hugging Face job. This ends a live workload and any work it has not checkpointed is lost. Cancelling an already finished or cancelled job is a no-op. | **required** `org`, `job_id` |
| `huggingface_export_audit_log` | Answer 'who in this Hugging Face organization did what' — member invites and removals, repo and Space changes, resource-group and billing actions. | **required** `org`, `start_time`, `end_time`<br />optional `actor`, `event_types`, `limit` |
| `huggingface_get_job_detail` | Inspect one Hugging Face job found via list_jobs — its stage, hardware, and timings. Add 'include' to pull in logs, metrics, or events. | **required** `org`, `job_id`<br />optional `include` |
| `huggingface_get_organization_usage` | Answer 'what is this Hugging Face organization spending on AI, and who is spending it'. | **required** `org`<br />optional `breakdown`, `end_date`, `limit`, `start_date` |
| `huggingface_list_jobs` | Answer 'what AI workloads are running in this Hugging Face organization right now'. Filter with 'stage' to a status stage (e.g. 'RUNNING') and with 'label' to key=value job labels. | **required** `org`<br />optional `cursor`, `label`, `limit`, `stage` |
| `huggingface_list_member_tokens` | Inventory the access tokens the organization's members hold — the credential half of 'how are my employees using AI'. Token values are never returned, only the last four characters. Revoked tokens are excluded unless status='all'. | **required** `org`<br />optional `cursor`, `limit`, `owner`, `role`, `status` |
| `huggingface_list_organization_members` | List the members of a Hugging Face organization and the org role each one holds. Use 'search' or 'email' to find one person. Pagination is by cursor: pass the previous response's 'cursor' back as 'cursor' while 'has_more' is true. | **required** `org`<br />optional `cursor`, `email`, `limit`, `search` |
| `huggingface_list_resource_groups` | List a Hugging Face organization's resource groups — the unit team-level access and spend limits are set on. Returns a summary per group with a member count; use list_organization_members to find who is in one. | **required** `org` |
| `huggingface_manage_resource_group_members` | Fix who is in one Hugging Face resource group: add members, change their role in the group, and remove them, in a single call. Removing a member revokes the access the group granted them. Pass at least one of 'add', 'set_role', 'remove'. | **required** `org`, `resource_group_id`<br />optional `add`, `remove`, `set_role` |
| `huggingface_revoke_member_token` | Revoke one member token's access to this organization — the incident-response action for a token flagged by secrets scanning or otherwise disclosed outside the org. | **required** `org`, `token_id` |
| `huggingface_update_member_access` | Set a member's organization role, and optionally their resource-group assignments, in one call. Changing a role can remove someone's access to repos and Spaces. | **required** `org`, `username`, `role`<br />optional `resource_groups` |
| `huggingface_update_resource_group_settings` | Reconfigure one Hugging Face resource group's governance: its auto-join policy and its spend limits. Spend limits are in whole US dollars — omit a limit to leave it alone, pass it as null to clear it. | **required** `org`, `resource_group_id`<br />optional `auto_join`, `spend_limits` |

## Jira

27 tools. Available as 2 connections: Jira (OAuth) (OAuth 2.0), Jira Data Center (Basic Auth) (Basic auth).

| Tool | Description | Arguments |
| --- | --- | --- |
| `jira_add_attachment` | Upload a file as a native attachment to a Jira issue by reference. The file appears in the issue's Attachments section — not as a comment. Pass `source_url`: a short-lived signed download URL minted by the `mint_upload_url` tool. | **required** `issue_key`, `file_name`, `source_url`<br />optional `mime_type` |
| `jira_add_issue_comment` | Add a comment to an existing Jira issue using Atlassian Document Format (ADF) for rich text; automatically converted to plain text for Data Center (API v2). | **required** `issue_key`, `body`<br />optional `internal` |
| `jira_assign_issue` | Assign, unassign, or auto-assign a Jira issue. Jira Cloud uses accountId and also supports "-1" for automatic assignment. Jira Data Center/Server uses username. | **required** `issue_id_or_key`<br />optional `assignee_identifier` |
| `jira_create_issue` | Create a new Jira issue (or sub-task) in a project. Description must be Atlassian Document Format (ADF); automatically converted to plain text for Data Center (API v2). | **required** `project_key`, `summary`<br />optional `custom_fields`, `description`, `issue_type_name`, `parent_issue_id`, `parent_issue_key`, `priority_id`, `priority_name` |
| `jira_create_issue_link` | Create a link between two Jira issues to establish a relationship (e.g., "blocks", "duplicates", "relates to"). Use list_issue_link_types to discover available link types for your Jira instance. | **required** `outward_issue_key`, `inward_issue_key`, `link_type_name` |
| `jira_create_project` | Create a new Jira project. | **required** `project_key`, `project_name`<br />optional `lead_account_id`, `project_type_key`, `template_name` |
| `jira_create_webhook` | Create a new webhook for a Jira instance. On Cloud, Jira auto-generates the webhook name. On Data Center, a default name is assigned. | **required** `url`, `events`<br />optional `filters` |
| `jira_delete_issue_link` | Delete an existing link between two Jira issues | **required** `link_id` |
| `jira_delete_project` | Delete a Jira project by key | **required** `project_key` |
| `jira_delete_webhooks` | Delete one or more webhooks. On Jira Cloud, sends `{webhookIds}` to `/rest/api/3/webhook` and returns the upstream response (or `{deleted: N}` when the API responds with no body). | **required** `webhook_ids` |
| `jira_download_attachment_to_kindo_library` | Download a Jira attachment's binary content into the Kindo file library so the LLM can read it. | **required** `attachment_id` |
| `jira_get_create_metadata` | Get metadata for creating issues, including all available fields and their allowed values for a project/issue type. | optional `expand`, `issue_type_ids`, `issue_type_names`, `project_ids`, `project_keys` |
| `jira_get_edit_metadata` | Get metadata for editing a specific issue, including all editable fields and their allowed values. RECOMMENDED: Use this before update_issue to discover which fields can be edited and valid option values for select-type fields. | **required** `issue_key` |
| `jira_get_field_options` | Get available options for a select-type custom field (dropdown, multi-select, radio buttons, checkboxes). Returns option IDs and values that can be used when setting the field. | **required** `field_id`<br />optional `context_id`, `max_results`, `start_at` |
| `jira_get_issue` | Retrieve a Jira issue by key or ID | **required** `issue_key`<br />optional `expand`, `fields`, `fields_by_keys`, `properties` |
| `jira_get_issue_link` | Retrieve details of a specific issue link by its ID | **required** `link_id` |
| `jira_get_project` | Retrieve a Jira project by key | **required** `project_key`<br />optional `expand`, `properties` |
| `jira_get_webhook` | Get details of a specific webhook by id. | **required** `webhook_id` |
| `jira_list_fields` | List all fields (system and custom) available in the Jira instance. Use this to discover custom field IDs (e.g., 'customfield_10110') and their types. | optional `field_type` |
| `jira_list_issue_link_types` | List all available issue link types in the Jira instance (e.g., "Blocks", "Duplicate", "Relates"). Link types are directional with inward and outward descriptions. | — |
| `jira_list_issue_links` | List all links for a specific Jira issue, showing both inward and outward relationships | **required** `issue_key` |
| `jira_list_webhooks` | List webhooks for a Jira instance. | optional `max_results`, `start_at` |
| `jira_refresh_webhooks` | Renew (extend the life of) dynamic webhooks registered by this app. | **required** `webhook_ids` |
| `jira_search_issues` | Search issues using JQL. JQL queries should include search restrictions to avoid large result sets. | **required** `jql`<br />optional `fields`, `max_results`, `page_token` |
| `jira_transition_issue` | Transition a Jira issue to another workflow state. | **required** `issue_key`, `transition_id`<br />optional `comment`, `fields`, `update` |
| `jira_update_issue` | Update fields of a Jira issue. Supports summary, description, issue type, parent (for sub-tasks), common system fields (priority, assignee, labels, fix_versions, components), and arbitrary custom fields via custom_fields. | **required** `issue_key`<br />optional `assignee_id`, `components`, `custom_fields`, `description`, `fix_versions`, `issue_type_name`, `labels`, `parent_issue_id`, `parent_issue_key`, `priority_id`, `priority_name`, `summary` |
| `jira_update_project` | Update fields in an existing Jira project | **required** `project_key`<br />optional `lead_account_id`, `new_key`, `new_name` |

## Linear

47 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `linear_archive_issue` | Archive a Linear issue by ID or identifier (e.g., TEAM-123). Archived issues are hidden from active views and can be restored from the team archive | **required** `issue_id` |
| `linear_batch_update_issues` | Update multiple Linear issues at once with a shared update payload (max 250 issues per call). When setting state or cycle by name, all issues should belong to the same team; use UUIDs for cross-team batches. | **required** `ids`<br />optional `assignee`, `cycle`, `description`, `due_date`, `estimate`, `labels`, `milestone`, `parent_id`, `priority`, `project`, `state`, `team`, `title` |
| `linear_create_comment` | Create a comment on a Linear issue with optional threaded reply support | **required** `issue_id`, `body`<br />optional `parent_id` |
| `linear_create_customer` | Create a customer in Linear with optional owner, tier, and status lookups | **required** `name`<br />optional `domains`, `external_ids`, `logo_url`, `main_source_id`, `owner`, `revenue`, `size`, `slack_channel_id`, `status`, `tier` |
| `linear_create_customer_request` | Create a Linear customer request linked to exactly one existing issue or project. Provide exactly one of `issue` or `projectId`; customer and body alone are not enough. | optional `attachment_url`, `body`, `customer`, `customer_external_id`, `issue`, `priority`, `project_id` |
| `linear_create_initiative` | Create a new Linear initiative. Returns a minimal acknowledgement ({id, url, name, status}); use get_initiative to fetch full detail, and update_initiative to add projects to it. | **required** `name`<br />optional `description`, `owner`, `status`, `target_date` |
| `linear_create_issue` | Create a new Linear issue with support for sub-issues and name-based lookups | **required** `title`, `team`<br />optional `assignee`, `cycle`, `description`, `due_date`, `estimate`, `labels`, `milestone`, `parent_id`, `priority`, `project`, `state` |
| `linear_create_issue_label` | Create a new Linear issue label | **required** `name`<br />optional `color`, `description`, `is_group`, `parent_id`, `team_id` |
| `linear_create_project` | Create a new project in Linear with lead and label management | **required** `name`, `team`<br />optional `color`, `description`, `icon`, `label_ids`, `lead`, `start_date`, `state`, `summary`, `target_date` |
| `linear_create_project_update` | Create a new status update for a Linear project | **required** `project`, `body`<br />optional `health`, `is_diff_hidden` |
| `linear_delete_issue` | Delete a Linear issue by ID or identifier (e.g., TEAM-123). The issue is moved to trash and permanently deleted after 30 days | **required** `issue_id` |
| `linear_delete_project_update` | Delete a project update | **required** `project_update_id` |
| `linear_get_active_cycle` | Get the active cycle for a team | **required** `team` |
| `linear_get_customer` | Get a specific customer by UUID or name including tier and status information | **required** `customer` |
| `linear_get_customer_request` | Get a specific customer request by ID | **required** `customer_request_id`<br />optional `include_body_data` |
| `linear_get_document` | Retrieve a Linear document by ID or slug | **required** `document_id` |
| `linear_get_initiative` | Retrieve one Linear initiative with rollup detail: status, health, owner, target date, description, and the first 25 projects it contains (with state and progress). | **required** `query` |
| `linear_get_issue` | Retrieve a Linear issue details by ID, including attachments and customer needs | **required** `issue_id` |
| `linear_get_issue_status` | Retrieve details of a specific issue status in Linear by name or ID | **required** `query`, `team` |
| `linear_get_project` | Retrieve details of a specific project in Linear | **required** `query` |
| `linear_get_project_update` | Get details of a specific project update | **required** `project_update_id` |
| `linear_get_team` | Retrieve details of a specific Linear team | **required** `query` |
| `linear_get_user` | Retrieve details of a specific Linear user | **required** `query` |
| `linear_link_issues` | Create a relationship between two Linear issues | **required** `issue_id`, `related_issue_id`, `relation_type` |
| `linear_list_comments` | Retrieve comments for a Linear issue by ID | **required** `issue_id`<br />optional `after`, `before`, `limit` |
| `linear_list_customer_requests` | List customer requests with enhanced filtering and customer name lookup support | optional `after`, `before`, `created_at`, `customer`, `include_archived`, `issue_id`, `limit`, `order_by`, `priority`, `updated_at` |
| `linear_list_customers` | List customers with enhanced search and filtering capabilities | optional `after`, `before`, `created_at`, `include_archived`, `limit`, `name`, `order_by`, `query`, `status_id`, `tier_id`, `updated_at` |
| `linear_list_cycles` | List cycles for a team with enhanced filtering | **required** `team`<br />optional `after`, `before`, `cycle_type`, `include_completed`, `limit` |
| `linear_list_documents` | List documents in the Linear workspace with advanced filtering | optional `after`, `before`, `created_at`, `creator`, `include_archived`, `initiative_id`, `limit`, `order_by`, `project`, `query`, `updated_at` |
| `linear_list_initiatives` | List initiatives (the strategic grouping above projects) in the Linear workspace, with filtering by name, status, and owner. | optional `after`, `before`, `created_at`, `include_archived`, `limit`, `order_by`, `owner`, `query`, `status`, `updated_at` |
| `linear_list_issue_labels` | List available issue labels in a Linear team | optional `after`, `before`, `limit`, `name`, `team_id` |
| `linear_list_issue_relations` | List all relationships for a Linear issue | **required** `issue_id` |
| `linear_list_issue_statuses` | List available issues statuses in a Linear team | **required** `team` |
| `linear_list_issues` | List issues in the user's Linear workspace with comprehensive filtering. Supports bulk fetch by passing an array of IDs (UUIDs or identifiers like TEAM-123). | optional `after`, `assignee`, `before`, `created_at`, `customer`, `customer_request`, `cycle`, `ids`, `include_archived`, `label`, `limit`, `order_by`, `parent_id`, `project`, `query`, `state`, `team`, `updated_at`, `view` |
| `linear_list_my_issues` | List issues assigned to the current user | optional `after`, `before`, `limit`, `order_by`, `state` |
| `linear_list_project_updates` | List status updates for a Linear project | **required** `project`<br />optional `after`, `before`, `include_archived`, `limit`, `order_by` |
| `linear_list_projects` | List projects in the user's Linear workspace with enhanced filtering. Pass `initiative` (UUID or name) to list only the projects belonging to that initiative. | optional `after`, `before`, `created_at`, `include_archived`, `initiative`, `limit`, `order_by`, `query`, `state`, `team`, `updated_at` |
| `linear_list_teams` | Retrieve teams in the Linear workspace with comprehensive filtering | optional `after`, `before`, `created_at`, `include_archived`, `limit`, `order_by`, `query`, `updated_at` |
| `linear_list_users` | Retrieve users in the Linear workspace with search functionality | optional `after`, `before`, `include_archived`, `limit`, `query`, `team` |
| `linear_list_views` | List custom views in Linear workspace | optional `after`, `before`, `creator`, `include_archived`, `limit`, `order_by`, `team` |
| `linear_unarchive_issue` | Restore an archived or trashed Linear issue by ID or identifier (e.g., TEAM-123), returning it to active views | **required** `issue_id` |
| `linear_update_customer` | Update an existing customer in Linear by UUID or name | **required** `customer`<br />optional `domains`, `external_ids`, `logo_url`, `main_source_id`, `name`, `owner`, `revenue`, `size`, `slack_channel_id`, `status`, `tier` |
| `linear_update_customer_request` | Update a Linear customer request. If you are re-linking it, provide only one of `issue` or `projectId`. | **required** `customer_request_id`<br />optional `attachment_url`, `body`, `customer`, `customer_external_id`, `issue`, `priority`, `project_id` |
| `linear_update_initiative` | Update a Linear initiative and/or manage its project membership in one call. Set status to Completed or Canceled to close an initiative. | **required** `query`<br />optional `add_projects`, `description`, `name`, `owner`, `remove_projects`, `status`, `target_date` |
| `linear_update_issue` | Update an existing Linear issue | **required** `issue_id`<br />optional `assignee`, `cycle`, `description`, `due_date`, `estimate`, `labels`, `milestone`, `parent_id`, `priority`, `project`, `state`, `team`, `title` |
| `linear_update_project` | Update an existing Linear project with lead and label management | **required** `project_id`<br />optional `color`, `description`, `icon`, `label_ids`, `lead`, `name`, `start_date`, `state`, `summary`, `target_date` |
| `linear_update_project_update` | Update an existing project update | **required** `project_update_id`<br />optional `body`, `health`, `is_diff_hidden` |

## Sourcegraph

11 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `sourcegraph_commit_search` | Search commits by message, author, content, files, and date ranges. Use Cases: - Finding commits that modified specific code - Tracking changes by specific authors - Analyzing commit history | **required** `repos`<br />optional `after`, `authors`, `before`, `contentTerms`, `files`, `messageTerms` |
| `sourcegraph_compare_revisions` | Compare changes between two specific revisions. Use Cases: - Reviewing changes between releases - Understanding what changed in a PR - Comparing branches | **required** `repo`, `base`, `head`<br />optional `after`, `first` |
| `sourcegraph_diff_search` | Search actual code changes for specific patterns across repositories. Use Cases: - Finding when specific code was added or removed - Tracking changes to specific patterns - Code archaeology | **required** `pattern`, `repos`<br />optional `added`, `after`, `author`, `before`, `removed` |
| `sourcegraph_get_branch_list` | List all branches in a repository. Use Cases: - Finding available branches - Exploring repository structure - Selecting branches for comparisons | **required** `repo`<br />optional `limit` |
| `sourcegraph_get_contributor_repos` | Find repositories where a specific contributor has made commits. Use Cases: - Discovering a contributor's work across repositories - Analyzing contribution patterns - Finding related repositories by author | **required** `author`<br />optional `after`, `limit`, `minCommits` |
| `sourcegraph_get_repo_stats` | Get repository statistics including stars and last commit date. Use Cases: - Evaluating repository popularity - Checking repository activity - Getting quick overview of a repository | **required** `repo` |
| `sourcegraph_get_repository` | Get detailed information about a specific repository including default branch, description, and languages. | **required** `repo` |
| `sourcegraph_keyword_search` | Perform exact keyword searches with boolean operators and filters. | **required** `query` |
| `sourcegraph_list_files` | List files and directories in a repository path. Use Cases: - Exploring repository structure - Finding files in specific directories - Navigating codebases | **required** `repo`<br />optional `path`, `revision` |
| `sourcegraph_list_repos` | Search and list repositories by name patterns. Use Cases: - Finding repositories by name - Discovering related repositories - Scoping searches to specific repositories | **required** `query`<br />optional `limit` |
| `sourcegraph_read_file` | Read file contents from a Sourcegraph repository with support for specific line ranges and revisions. | **required** `repo`, `path`<br />optional `endLine`, `revision`, `startLine` |

---

## Vulnerability and exposure

Source: https://docs.kindo.ai/reference/tool-catalog/vulnerability-exposure/

:::note[Beta]
The tool catalog is in beta and is a point-in-time snapshot of the integration inventory, so an entry can differ from what your organization sees in product.
:::

Scanners and exposure-management platforms an agent can query for findings and asset coverage. 19 integrations, 281 tools.

Tool names below are the fully qualified names an agent sees once the integration is connected. Where an integration offers more than one connection, the names shown use the primary connection's prefix; connecting through another variant prefixes its tools with that variant's own integration ID instead. See [Tool Catalog](/reference/tool-catalog/) for how tools are granted and named.

## Armis Centrix

9 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `armis_get_alert` | Fetch a single Armis alert by its numeric ID. Returns full alert metadata including severity, status, policy, affected device, and evidence. Returns an empty object if the alert is not found. | **required** `alert_id` |
| `armis_get_device` | Fetch a single Armis device by its numeric ID. Returns the full device profile including risk score, OS, category, network info, tags, first/last seen, and any attached vulnerabilities. Returns an empty object if the device is not found. | **required** `device_id` |
| `armis_get_vulnerability` | — | **required** `vulnerability_id` |
| `armis_get_vulnerability_exposure` | List the device-CVE matches for ONE CVE or ONE device, each with its VIPR remediation lifecycle status — this answers 'who is exposed to this CVE, and where does each exposure stand?'. | optional `cve_id`, `device_id`, `limit`, `offset`, `status` |
| `armis_run_asq_query` | — | **required** `aql`<br />optional `limit` |
| `armis_search_alerts` | — | optional `asq_filter`, `limit` |
| `armis_search_devices` | — | optional `asq_filter`, `limit` |
| `armis_search_vulnerabilities` | — | optional `asq_filter`, `limit` |
| `armis_summarize_remediation_posture` | Summarize VIPR remediation posture for a scope: how many findings sit in each lifecycle status and severity tier, plus the highest-priority open findings. | optional `asq_filter`, `top` |

## Bitsight

19 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `bitsight_create_company_request` | Request that a company be added to the Bitsight inventory by domain so it can later be monitored. Mapping is asynchronous (typically 3-10 days). Optionally set a subscription_type to auto-subscribe once added. | **required** `domain`<br />optional `subscription_type` |
| `bitsight_get_company` | Get full details for a single company: current rating, rating history, and risk-vector grades. Requires a company_guid (use search_companies to resolve one from a name or domain). | **required** `company_guid` |
| `bitsight_get_company_request` | Get the details and status of a single company-addition request. | **required** `request_guid` |
| `bitsight_get_portfolio_risk_vector_grades` | Get per-risk-vector letter grades for companies in your portfolio (e.g. Botnet Infections, Patching Cadence). Optionally scope to a folder, tier, or single company, and choose latest grades or a 1-year monthly history. | optional `company_guid`, `folder_guid`, `limit`, `period`, `tier_guid` |
| `bitsight_get_portfolio_statistics` | Get aggregate statistics across your portfolio: distribution by rating category (advanced/intermediate/basic), highest/lowest/median ratings, and risk-vector averages. | — |
| `bitsight_get_subscription_info` | Get subscription/entitlement information: per-product quotas and remaining capacity. Useful to distinguish a 403 'not entitled' from a genuine error and to check available monitoring slots. | — |
| `bitsight_get_threat_evidence` | Get a specific company's evidence for a given threat: certainty, exposure detection, and evidence tags. Requires both the threat_guid (from list_threats) and the company_guid. | **required** `threat_guid`, `company_guid`<br />optional `limit` |
| `bitsight_get_vendor_action_plan` | Get vendor company GUIDs grouped by recommended action plan (monitor / review / escalate) across your tiers. | — |
| `bitsight_list_alerts` | List Continuous Monitoring alerts (rating changes, threshold breaches, risk-vector grade changes, public disclosures, vulnerabilities). Filter by type, severity, company, folder, and date range. | optional `alert_type`, `company_guid`, `end_date`, `folder_guid`, `latest`, `limit`, `severity`, `start_date` |
| `bitsight_list_breach_events` | List public-disclosure 'company events' (breaches and security incidents) impacting portfolio companies. Optionally scope to a single company. Each event includes type, category, description, severity, and the affected company. | optional `company_guid`, `limit` |
| `bitsight_list_company_findings` | List security findings for a company, or a rolled-up summary. Findings are the underlying evidence (events/records) behind a company's rating. Set summary=true for aggregate counts instead of individual findings. | **required** `company_guid`<br />optional `limit`, `summary` |
| `bitsight_list_company_requests` | List existing company-addition requests and their status. | optional `limit` |
| `bitsight_list_company_tree` | List a company's ratings tree — the company plus its subsidiaries (recursive corporate hierarchy) — for fourth-party / supply-chain analysis. | **required** `company_guid` |
| `bitsight_list_folders` | List the folders used to group portfolio companies (and that drive alerts and reporting). Returns folder GUIDs, names, and sharing details. | — |
| `bitsight_list_portfolio` | List the companies in your Continuous Monitoring portfolio along with their current security ratings. Optionally scope to a folder or tier. | optional `folder_guid`, `limit`, `tier_guid` |
| `bitsight_list_ratings_tree_product_types` | List the product types used by all companies in a third party's ratings tree (parent + subsidiaries), for fourth-party concentration / supply-chain risk analysis. | **required** `company_guid` |
| `bitsight_list_threats` | List portfolio threats (vulnerabilities and vulnerability groups) detected across monitored companies. Filter by impact scope, severity, folder, and tier. Each threat reports exposed/mitigated counts and CVSS. | optional `folder_guid`, `impact`, `limit`, `severity`, `tier_guid` |
| `bitsight_list_tiers` | List vendor tiers used to prioritize vendors by criticality. Set summary=true for per-tier summary statistics instead of tier records. | optional `summary` |
| `bitsight_search_companies` | Search the Bitsight inventory by company name and/or domain to find a company_guid. This is the entry point for most workflows — almost every other tool needs a company_guid that this call resolves. | optional `domain`, `limit`, `name` |

## Black Duck

14 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `black-duck_generate_sbom_report` | Trigger SBOM (Software Bill of Materials) report generation for a project version. Supports SPDX 2.2 (JSON, YAML, RDF, TAG_VALUE) and CycloneDX 1.4 (JSON, YAML, XML). Note: TAG_VALUE is SPDX-only; XML is CycloneDX-only. | **required** `project_id`, `version_id`<br />optional `sbom_format`, `sbom_type` |
| `black-duck_get_component_vulnerabilities` | Get all vulnerabilities for a specific component version. Returns CVE/BDSA IDs, CVSS v3 scores, severity, and descriptions (CVSS v4 fields are populated only on Black Duck 2025.1+). | **required** `component_id`, `component_version_id`<br />optional `limit`, `offset` |
| `black-duck_get_project` | Get details of a single Black Duck project by its project ID. | **required** `project_id` |
| `black-duck_get_project_version` | Get details of a specific project version including its risk profile (vulnerability counts broken down by CRITICAL, HIGH, MEDIUM, LOW severity). | **required** `project_id`, `version_id` |
| `black-duck_get_project_vulnerability_digest` | Get per-project vulnerability digest showing severity breakdown. Available in Black Duck 2025.10 and later. Returns each project's vulnerability counts by severity. | optional `limit`, `offset` |
| `black-duck_get_vulnerability_digest_summary` | Get an org-wide summary of vulnerability counts broken down by severity (CRITICAL, HIGH, MEDIUM, LOW). Available in Black Duck 2025.10 and later. Useful for a quick health overview across all projects. | — |
| `black-duck_get_vulnerability_remediation` | Get the remediation details for a specific vulnerability on a BOM component in a project version. Returns current remediation status, CVSS v3 scores (CVSS v4 fields require Black Duck 2025.1+), fix guidance, and comments. | **required** `project_id`, `version_id`, `component_id`, `component_version_id`, `vulnerability_id` |
| `black-duck_list_bom_components` | List all bill-of-materials (BOM) components for a project version. Returns open-source components with their license info and policy status. | **required** `project_id`, `version_id`<br />optional `limit`, `offset` |
| `black-duck_list_policy_rules` | List all Black Duck policy rules. Policy rules define conditions (e.g., CRITICAL severity, specific licenses) that flag BOM components as policy violations. | optional `limit`, `offset` |
| `black-duck_list_project_versions` | List all versions (scans) for a Black Duck project. Each version has a risk profile showing vulnerability counts by severity. | **required** `project_id`<br />optional `limit`, `offset` |
| `black-duck_list_projects` | List Black Duck SCA projects. Optionally filter by name substring. Returns project IDs, names, descriptions, and creation metadata. | optional `limit`, `name`, `offset` |
| `black-duck_list_reports` | List generated reports for a project version. Returns report IDs, types, formats, and status (REQUESTED, IN_PROGRESS, COMPLETED). | **required** `project_id`, `version_id`<br />optional `limit`, `offset` |
| `black-duck_list_vulnerable_bom_components` | List only the vulnerable open-source components in a project version's BOM. Each result includes CVSS scores, severity, and current remediation status. Filter by severity or remediation status to focus the results. | **required** `project_id`, `version_id`<br />optional `limit`, `offset`, `remediation_status`, `severity` |
| `black-duck_update_vulnerability_remediation` | Update the remediation status for a specific vulnerability on a BOM component. Use to mark vulnerabilities as AFFECTED, NOT_AFFECTED, REMEDIATED, IGNORED, etc. | **required** `project_id`, `version_id`, `component_id`, `component_version_id`, `vulnerability_id`, `remediation_status`<br />optional `comment` |

## Burp Suite DAST

15 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `burp-suite_cancel_scan` | Cancel a running or queued Burp Suite DAST scan. This is irreversible — the scan cannot be resumed and any incomplete results are discarded. Returns the scan's `id` and updated `status` so the caller can verify cancellation. | **required** `scan_id` |
| `burp-suite_create_site` | Register a new target site in Burp Suite DAST with scope URLs and optional scan configuration. Returns the created site's id, name, parent_id, scope (included_urls, excluded_urls), and scan_configuration_ids. | **required** `name`, `included_urls`<br />optional `excluded_urls`, `parent_id`, `scan_configuration_ids` |
| `burp-suite_get_compliance_report` | Get a compliance report for a Burp Suite DAST scan. Supported report types: 'PCI DSS v4.0.1' or 'OWASP Top 10 2025'. Returns the plain-text report content describing each requirement's status. | **required** `scan_id`, `report_type` |
| `burp-suite_get_issue` | Get full details of a specific vulnerability from a Burp Suite DAST scan, including plain-text description, remediation guidance, evidence, vulnerability classifications, and references. | **required** `scan_id`, `serial_number` |
| `burp-suite_get_scan` | Get full details of a Burp Suite DAST scan by ID, including status, site_id, site_name, start/end time, scan_configuration_ids, issue counts by severity, and delta vs. the previous scan. | **required** `scan_id` |
| `burp-suite_get_scan_event_log` | Get the event timeline for a Burp Suite DAST scan. Each entry includes an event type, message, and timestamp. Useful for diagnosing stuck, failed, or unexpectedly short scans. Use limit to cap the number of entries returned. | **required** `scan_id`<br />optional `event_type`, `limit` |
| `burp-suite_get_site` | Get details of a specific Burp Suite DAST site by ID, including scope (included/excluded URLs and protocol options), assigned scan configurations, agent pool assignment, and configured application logins. | **required** `site_id` |
| `burp-suite_list_agents` | List all scanning agents registered in Burp Suite DAST, with their enabled/active status, max concurrent scans, agent pool assignment, and machine endpoints (ip/port). Useful for checking scanning capacity before scheduling large scans. | — |
| `burp-suite_list_issues` | List vulnerabilities found in a Burp Suite DAST scan. Returns issue type, name, path, severity, confidence, and triage status. Supports pagination via start (0-based offset) and count (max 500). | **required** `scan_id`<br />optional `count`, `start` |
| `burp-suite_list_scan_configurations` | List all available scan configurations in Burp Suite DAST — both PortSwigger built-in configurations and custom configurations. Returns ID and name for each configuration. | — |
| `burp-suite_list_scans` | List scans in Burp Suite DAST with optional filtering by site, sort order, and result limit. Returns scan status, timing, issue counts by severity, and delta vs. the previous scan per row. | optional `limit`, `site_id`, `sort_column`, `sort_order` |
| `burp-suite_list_sites` | List all sites and folders in the Burp Suite DAST site tree. Returns an object with two keys: 'folders' (list of folder records with id, name, parent_id) and 'sites' (list of site records with id, name, parent_id). | — |
| `burp-suite_run_pre_scan_check` | Verify that a Burp Suite DAST site is reachable before scheduling a scan. Returns the reachability check state and any failure message. Run this before schedule_scan to avoid wasted scan capacity. | **required** `site_id` |
| `burp-suite_schedule_scan` | Schedule a new scan for a Burp Suite DAST site. Supports one-time scans and recurring scans via an iCalendar RRULE string. | **required** `site_id`, `initial_run_time`<br />optional `rrule`, `scan_configuration_id` |
| `burp-suite_update_issue` | Triage a Burp Suite DAST vulnerability: mark it as a false positive, mark it as accepted risk, or adjust its severity. At least one of false_positive, accepted_risk, or severity must be provided. | **required** `scan_id`, `serial_number`<br />optional `accepted_risk`, `false_positive`, `severity` |

## Cyberhaven

39 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cyberhaven__body_action_tool` | — | **required** `resource_id`, `body` |
| `cyberhaven__create_tool` | — | **required** `body` |
| `cyberhaven__delete_tool` | — | **required** `resource_id` |
| `cyberhaven__get_list_tool` | — | optional `filters` |
| `cyberhaven__get_tool` | — | **required** `resource_id` |
| `cyberhaven__post_list_tool` | — | optional `filters`, `limit`, `next_id` |
| `cyberhaven__update_tool` | — | **required** `resource_id`, `body` |
| `cyberhaven__upsert_tool` | — | **required** `body`<br />optional `resource_id` |
| `cyberhaven_add_list_items` | Add one or more items to a Cyberhaven list. | **required** `list_id`, `items` |
| `cyberhaven_add_risk_group_user` | Add a user to a manual Cyberhaven user risk group by alias. | **required** `risk_group_id`, `user_alias` |
| `cyberhaven_build_incident_filter_template` | Build a local Cyberhaven incident-filter template without making an API call. | optional `date_from`, `date_to`, `policy`, `severity`, `status`, `user` |
| `cyberhaven_bulk_add_risk_group_users` | Add multiple users to a manual Cyberhaven user risk group in a single workflow. Used by the IRM workflow to flag contractors, departing employees, or watchlisted users. | **required** `risk_group_id`, `user_aliases` |
| `cyberhaven_bulk_assign_incidents` | Find incidents matching filters, then assign them to a Cyberhaven analyst or owner using per-incident PATCH calls. Individual PATCH failures do not abort the batch. | **required** `filters`, `assignee`<br />optional `max_updates`, `note` |
| `cyberhaven_bulk_close_incidents` | Find incidents matching filters, then close them in a batch workflow using per-incident PATCH calls. Individual PATCH failures do not abort the batch. | **required** `filters`<br />optional `max_updates`, `note` |
| `cyberhaven_check_risk_group_user` | Quick lookup to check if a user is part of a specific risk group. | **required** `risk_group_id`, `user_alias` |
| `cyberhaven_compare_periods` | Return side-by-side Cyberhaven incident metrics for two explicit filter periods. | **required** `current_filters`, `previous_filters`<br />optional `max_results` |
| `cyberhaven_correlate_user_activity` | Correlate Cyberhaven incidents and IRM activity for a user-centric investigation. Resolves the user via IRM search and uses their canonical identifier (email/alias/id) for the incident filter. | **required** `user`<br />optional `incident_filters`, `max_incidents` |
| `cyberhaven_format_report_data` | Format arbitrary data as markdown or return it unchanged as JSON without making an API call. | **required** `title`, `data`<br />optional `output_format` |
| `cyberhaven_generate_report` | Generate a compact Cyberhaven report from incident, policy, or user-focused workflows. Returns a markdown string when output_format is MARKDOWN (default), or the raw report dict when output_format is JSON. | **required** `report_type`<br />optional `filters`, `output_format` |
| `cyberhaven_get_activity_timeline` | Build a simple chronological activity timeline for a Cyberhaven user investigation. Returns an empty list when no IRM user matches the query — this tool will not silently operate on an arbitrary user. | **required** `user` |
| `cyberhaven_get_event_details` | Get full Cyberhaven event details for one or more event identifiers. Use this to enrich incident investigations with raw event context. | **required** `event_ids` |
| `cyberhaven_get_event_lineage` | Get Cyberhaven event lineage or chain-of-custody context between two events. Useful when tracking how data moved across users, endpoints, or applications. | **required** `start_event_id`, `end_event_id` |
| `cyberhaven_get_incident` | Get a single Cyberhaven incident by ID. Cyberhaven does not expose a direct GET endpoint, so this filters /v2/incidents/list by ID and returns the matching incident. Returns an empty object if not found. | **required** `resource_id` |
| `cyberhaven_get_irm_user` | Get a single Cyberhaven IRM user (including risk-profile fields) by alias. Cyberhaven does not expose a direct GET endpoint, so this filters /v2/irm/users by alias and returns the matching user. | **required** `resource_id` |
| `cyberhaven_get_list_items` | Get paginated items of a Cyberhaven list. | **required** `list_id`<br />optional `page_id`, `page_size` |
| `cyberhaven_get_streaming_profile_connection_log` | Get streaming profile connection log entries. Use this when a forwarding target is failing or dropping events. | **required** `profile_id`<br />optional `end_time`, `error_filter`, `page_id`, `page_size`, `start_time` |
| `cyberhaven_get_user_activity` | Get a consolidated Cyberhaven activity view for a user, including incidents and risky dataflows. Returns empty incidents/dataflows when no IRM user matches the query — this tool will not silently operate on an arbitrary user. | **required** `user` |
| `cyberhaven_investigate_user` | Run a focused user investigation using IRM user search, risky dataflows, and matching incidents. User matching is an exact match on id/email/alias and a substring match on name. | **required** `user`<br />optional `incident_filters`, `max_incidents` |
| `cyberhaven_list_irm_user_risky_dataflows` | List risky dataflows associated with a Cyberhaven IRM user. | **required** `user_id`<br />optional `events_time_from`, `events_time_to`, `limit` |
| `cyberhaven_list_risk_group_users` | List user aliases in a Cyberhaven user risk group. | **required** `risk_group_id` |
| `cyberhaven_merge_filter_sets` | Merge two local Cyberhaven filter objects without making an API call. | **required** `base_filters`, `override_filters` |
| `cyberhaven_policy_effectiveness` | Grade policies by correlating Cyberhaven policy resources with incident volume. | optional `incident_filters`, `max_incidents`, `policy_filters` |
| `cyberhaven_remove_list_items` | Remove one or more items from a Cyberhaven list. | **required** `list_id`, `items` |
| `cyberhaven_remove_risk_group_user` | Remove a user from a manual Cyberhaven user risk group by alias. | **required** `risk_group_id`, `user_alias` |
| `cyberhaven_replace_risk_group_users` | **DESTRUCTIVE: full replacement** — overwrites the complete user membership of a manual Cyberhaven user risk group with the supplied list. | **required** `risk_group_id`, `user_aliases` |
| `cyberhaven_reset_irm_user_risk_scores` | Reset Cyberhaven IRM risk scores for one or more users. | **required** `user_ids` |
| `cyberhaven_search_irm_users` | Search Cyberhaven IRM users by free-text query. Matches against display name, alias, title, department, and hostname fields on the IRM user record. For an exact alias lookup use get_irm_user. | **required** `query`<br />optional `filters`, `limit` |
| `cyberhaven_summarize_incidents` | Summarize Cyberhaven incidents for the supplied filter window. Returns counts grouped by status and severity, with a `truncated` flag indicating whether the per-period cap was hit. | **required** `current_filters`<br />optional `max_results`, `previous_filters` |
| `cyberhaven_update_incident` | Patch an incident to change ownership, workflow status, severity, or attach additional Cyberhaven fields. Use this for single-incident response actions. | **required** `resource_id`<br />optional `assignee`, `fields`, `note`, `severity`, `status` |

## Cyera

5 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cyera_get_datastore_objects` | List the data objects (tables, buckets, files) within a single Cyera data store by ID, including object type, location, and classification summary. Supports pagination. | **required** `datastore_id`<br />optional `limit`, `offset` |
| `cyera_list_classifications` | List Cyera classification results — the sensitive-data findings (e.g., PII, PCI, PHI) detected across data stores. Supports pagination and optional datastore filtering. | optional `datastore_id`, `limit`, `offset` |
| `cyera_list_datastores` | List data stores discovered by Cyera, including cloud provider, type, classification summary, and risk posture. Supports pagination and optional provider/type filtering. | optional `datastore_type`, `limit`, `offset`, `provider` |
| `cyera_list_events` | List Cyera events (audit/activity records such as discovery, classification, and issue changes) with optional time-range filtering and pagination. | optional `end_date`, `limit`, `offset`, `start_date` |
| `cyera_list_issues` | List Cyera security issues (data-risk findings) with optional filtering by severity and status. Returns issue summaries including title, severity, affected datastore, and status. | optional `limit`, `offset`, `severity`, `status` |

## Horizon3 NodeZero

13 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `horizon3-nodezero_cancel_pentest` | Cancel a running NodeZero pentest by its operation ID. | **required** `op_id` |
| `horizon3-nodezero_get_pentest` | Get detailed information about a specific NodeZero pentest by its operation ID. | **required** `op_id` |
| `horizon3-nodezero_get_pentest_report_url` | Get a download URL for a pentest's reports ZIP file. | **required** `op_id` |
| `horizon3-nodezero_get_runner` | Get detailed information about a specific NodeZero Runner (agent) by its UUID or name. Runners automate deployment of the NodeZero Docker container for internal pentests. Provide either uuid or name to identify the runner. | optional `name`, `uuid` |
| `horizon3-nodezero_get_weakness` | Get detailed information about a specific weakness found in a pentest. | **required** `op_id`, `weakness_id` |
| `horizon3-nodezero_list_action_logs` | List MITRE ATT&CK-mapped action logs for a specific pentest. Shows what NodeZero did during the pentest. | **required** `op_id`<br />optional `page`, `page_size` |
| `horizon3-nodezero_list_attack_paths` | List attack paths discovered during a specific pentest. Shows how NodeZero chained vulnerabilities. | **required** `op_id`<br />optional `page`, `page_size` |
| `horizon3-nodezero_list_credentials` | List credentials discovered during a specific pentest. | **required** `op_id`<br />optional `page`, `page_size` |
| `horizon3-nodezero_list_hosts` | List hosts discovered during a specific pentest. | **required** `op_id`<br />optional `page`, `page_size` |
| `horizon3-nodezero_list_pentests` | List all NodeZero pentests with pagination. Returns pentest IDs, names, states, and summary counts. | optional `page`, `page_size`, `text_search` |
| `horizon3-nodezero_list_runners` | List all NodeZero Runners (agents) configured in the account with pagination. | optional `page`, `page_size`, `text_search` |
| `horizon3-nodezero_list_weaknesses` | List weaknesses (vulnerabilities/findings) discovered in a specific pentest. | **required** `op_id`<br />optional `page`, `page_size`, `text_search` |
| `horizon3-nodezero_run_pentest` | Schedule and launch a new NodeZero pentest. Returns the operation ID and runner script URL. | **required** `name`<br />optional `op_type` |

## Microsoft Defender for Cloud

9 tools. Available as 2 connections: Microsoft Defender for Cloud (OAuth 2.0), Microsoft Defender for Cloud (Government) (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-defender-for-cloud_get_alert` | Get detailed information for a specific Defender for Cloud security alert. Returns full alert properties including severity, entities, attack tactics, remediation steps, and timeline. | **required** `alert_name`, `location` |
| `microsoft-defender-for-cloud_get_compliance_overview` | Get regulatory compliance status for a specific standard (e.g. Azure CIS, NIST, PCI-DSS, SOC 2). Shows which controls are passing/failing and their assessment counts. Use list_security_coverage first to see available standards. | **required** `standard_name` |
| `microsoft-defender-for-cloud_get_recommendation` | Get detailed information for a specific security recommendation (assessment). Returns the recommendation status, severity, affected resource details, and remediation guidance. | **required** `assessment_name`<br />optional `resource_id` |
| `microsoft-defender-for-cloud_get_secure_score` | Get the subscription's secure score with a breakdown by security controls. The secure score (0-100%) measures overall security posture. Each control groups related recommendations and contributes weighted points. | — |
| `microsoft-defender-for-cloud_list_alerts` | List Microsoft Defender for Cloud security alerts for the subscription. Alerts represent detected threats from enabled Defender plans (Defender for Servers, Storage, SQL, etc.). | optional `severity`, `status`, `top` |
| `microsoft-defender-for-cloud_list_recommendation_findings` | List sub-assessments (individual findings) for a recommendation. Shows which specific resources are affected and their individual status. For example, a recommendation 'Enable disk encryption' would show each VM that is missing encryption. | **required** `assessment_name`<br />optional `resource_id`, `top` |
| `microsoft-defender-for-cloud_list_recommendations` | List Defender for Cloud security recommendations (assessments) for the subscription. Recommendations identify misconfigurations and security gaps. Available in both free CSPM and paid plans. | optional `status`, `top` |
| `microsoft-defender-for-cloud_list_security_coverage` | List enabled Defender plans (pricing tiers) and available compliance standards. Helps understand what protection is active: free tier gives recommendations only, paid plans (Servers, Storage, SQL, Containers, etc.) add threat alerts. | — |
| `microsoft-defender-for-cloud_update_alert` | Update the status of a Defender for Cloud security alert. Use 'Dismissed' for false positives, 'Resolved' for handled threats, 'InProgress' for alerts under investigation, 'Active' to reactivate. | **required** `alert_name`, `location`, `status` |

## NVD

5 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `nvd_get_cpe` | Get detailed information about a specific CPE (Common Platform Enumeration) entry | **required** `cpeIdentifier` |
| `nvd_get_cve` | Get detailed information about a specific CVE by its ID | **required** `cveId` |
| `nvd_search_cpes` | Search for CPE (Common Platform Enumeration) entries to identify specific products and versions | optional `cpeMatchString`, `cpeNameId`, `keywordExactMatch`, `keywordSearch`, `lastModEndDate`, `lastModStartDate`, `matchCriteriaId`, `resultsPerPage`, `startIndex` |
| `nvd_search_cves` | Search for CVE vulnerabilities with various filters including keywords, dates, severity levels, and more | optional `cpeName`, `cvssV2Severity`, `cvssV3Severity`, `cweId`, `hasCertAlerts`, `hasCertNotes`, `hasKev`, `hasOval`, `isVulnerable`, `keyword`, `keywordExactMatch`, `lastModEndDate`, `lastModStartDate`, `noRejected`, `pubEndDate`, `pubStartDate`, `resultsPerPage`, `sourceIdentifier`, `startIndex` |
| `nvd_search_vulnerabilities_by_cpe` | Find vulnerabilities that affect a specific CPE (Common Platform Enumeration) | **required** `cpeName`<br />optional `resultsPerPage`, `startIndex` |

## Prisma Cloud

14 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `prisma-cloud_dismiss_alerts` | Dismiss or snooze one or more Prisma Cloud alerts. Provide a snooze duration to temporarily snooze instead of permanently dismissing. | **required** `alert_ids`, `dismissal_note`<br />optional `snooze_amount`, `snooze_unit` |
| `prisma-cloud_get_alert` | Get detailed information for a specific Prisma Cloud alert by ID | **required** `alert_id`<br />optional `detailed` |
| `prisma-cloud_get_alert_remediation` | Get remediation CLI commands for a specific Prisma Cloud alert. Returns actionable commands to fix the security issue. | **required** `alert_id` |
| `prisma-cloud_get_asset` | Get detailed information for a specific cloud asset by its RRN or ID | **required** `asset_id` |
| `prisma-cloud_get_compliance_posture` | Get compliance posture summary for a specific compliance standard, showing pass/fail statistics across requirements | **required** `compliance_id`<br />optional `cloud_account`, `cloud_type` |
| `prisma-cloud_get_policy` | Get detailed information for a specific Prisma Cloud policy by ID | **required** `policy_id` |
| `prisma-cloud_list_alert_rules` | List configured alert rules in Prisma Cloud | — |
| `prisma-cloud_list_alerts` | List Prisma Cloud security alerts with filtering by status, severity, cloud type, account, and policy name. Returns paginated results. | optional `account_name`, `cloud_type`, `detailed`, `limit`, `offset`, `policy_name`, `severity`, `status`, `time_amount`, `time_unit` |
| `prisma-cloud_list_asset_inventory` | List cloud asset inventory with filtering by cloud type, account, resource type, and region. Provides a breakdown of pass/fail statistics. | optional `account_name`, `cloud_type`, `group_by`, `region`, `resource_type`, `time_amount`, `time_unit` |
| `prisma-cloud_list_compliance_standards` | List all compliance standards and frameworks available in Prisma Cloud | — |
| `prisma-cloud_list_policies` | List Prisma Cloud security policies with filtering by severity, cloud type, policy type, compliance standard, and enabled status | optional `cloud_type`, `compliance_standard`, `enabled`, `policy_type`, `severity` |
| `prisma-cloud_reopen_alerts` | Reopen previously dismissed or snoozed Prisma Cloud alerts | **required** `alert_ids` |
| `prisma-cloud_search_config` | Search cloud resources using Prisma Cloud RQL (Resource Query Language) config queries. Example: "config from cloud.resource where cloud.type = 'aws' AND resource.type = 'aws_s3_bucket'" | **required** `query`<br />optional `limit`, `time_amount`, `time_unit` |
| `prisma-cloud_update_policy_status` | Enable or disable a Prisma Cloud security policy | **required** `policy_id`, `enabled` |

## Qualys

58 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `qualys_activate_agent` | Activate one or more Qualys modules (e.g. AGENT_VM, AGENT_PC) for a single asset's Cloud Agent. Additive and reversible via deactivate_agents. | **required** `asset_id`, `modules`<br />optional `base_url`, `pod` |
| `qualys_add_excluded_hosts` | Exclude IPs from vulnerability scanning. Excluded hosts will be skipped in future scans. | **required** `ips`<br />optional `comment` |
| `qualys_count_agents` | Count Cloud Agent host assets matching a tag filter (default tag 'Cloud Agent') plus optional QPS criteria. Cheap first call: use it before list_agents or any bulk action to gauge fleet size and blast radius. Uses the Qualys QPS REST API. | optional `base_url`, `criteria`, `pod`, `tag_name` |
| `qualys_create_asset_group` | Create a new asset group with a title and optional IP set. | **required** `title`<br />optional `comments`, `ips` |
| `qualys_create_tag` | Create a new asset tag. | **required** `name`<br />optional `color`, `parent_tag_id` |
| `qualys_csam_assets_by_tag` | Search CSAM/Global AssetView inventory for assets carrying a specific tag (tags.name filter). Convenience wrapper over csam_search_assets; returns the raw JSON response with lastSeenAssetId cursor pagination. | **required** `tag_name`<br />optional `base_url`, `last_seen_asset_id`, `page_size`, `pod` |
| `qualys_csam_assign_asset_business_metadata` | Assign business metadata (environment, ownership, businessAppIds, assignedLocation, etc.) to a CSAM asset. WRITE operation: dry-runs by default, returning the payload it would send; set confirm=True to execute. | **required** `qualys_asset_id`, `metadata`<br />optional `base_url`, `confirm`, `pod` |
| `qualys_csam_count_assets` | Count assets in the CSAM/Global AssetView inventory matching filter criteria (GAV/CSAM QQL field tokens). Uses the Qualys Gateway API. Optionally target a specific Qualys POD or override the gateway base URL. | optional `asset_last_updated`, `base_url`, `filters`, `last_seen_asset_id`, `pod` |
| `qualys_csam_get_asset` | Get full CSAM/Global AssetView details for a specific asset by its asset ID. Uses the Qualys Gateway API. | **required** `asset_id`<br />optional `base_url`, `pod` |
| `qualys_csam_list_business_apps` | List distinct business applications associated with assets in the CSAM inventory, derived from asset businessAppListData. Returns hasMore/lastSeenAssetId so additional asset pages can be swept for more apps. | optional `base_url`, `filters`, `last_seen_asset_id`, `page_size`, `pod` |
| `qualys_csam_search_assets` | Search the CSAM/Global AssetView asset inventory with filter criteria (GAV/CSAM QQL field tokens). Returns the raw JSON response including assetListData, hasMore, and lastSeenAssetId; pass lastSeenAssetId back to page through results. | optional `asset_last_updated`, `base_url`, `exclude_fields`, `filters`, `include_fields`, `last_seen_asset_id`, `page_size`, `pod` |
| `qualys_csam_upsert_business_app` | Create or update (upsert) a business application's metadata in CSAM. WRITE operation: dry-runs by default, returning the payload it would send; set confirm=True to execute. | **required** `business_app_id`, `name`<br />optional `base_url`, `confirm`, `created_epoch_millis`, `fields`, `last_updated_epoch_millis`, `pod` |
| `qualys_deactivate_agents` | Deactivate Qualys modules across a set of Cloud Agents (stops data collection for those modules). DESTRUCTIVE but reversible via activate_agent. Target by exactly one of asset_ids or tag_name. | **required** `modules`<br />optional `asset_ids`, `base_url`, `confirm`, `expected_count`, `pod`, `tag_name` |
| `qualys_delete_asset_group` | Delete an asset group by ID. DESTRUCTIVE AND IRREVERSIBLE. | **required** `group_id`<br />optional `confirm` |
| `qualys_delete_tag` | Delete an asset tag by ID. DESTRUCTIVE AND IRREVERSIBLE. Dry-runs by default, returning the tag's name and child-tag count for review; you MUST ask the user for explicit confirmation before re-calling with confirm=True to execute. | **required** `tag_id`<br />optional `confirm` |
| `qualys_export_compliance_policy` | Export a compliance policy definition by ID. | **required** `policy_id`<br />optional `response_format` |
| `qualys_export_option_profile` | Export one option profile's full configuration (scan settings, ports, search lists, performance) for VM (user), PC (compliance), or PCI profiles. Select by exactly one of profile_id or title (title must match exactly). | optional `profile_id`, `profile_type`, `response_format`, `title` |
| `qualys_fo_request` | Escape hatch: call any Qualys FO classic API endpoint under /api/2.0/fo/ when no dedicated tool covers it. | **required** `path`<br />optional `base_url`, `body`, `extra_headers`, `method`, `pod`, `query_params` |
| `qualys_gateway_request` | Escape hatch: call any Qualys Gateway API endpoint under /rest/2.0/ (GAV/CSAM) or /csapi/ (Container Security) (JSON) when no dedicated tool covers it. | **required** `path`<br />optional `base_url`, `body`, `extra_headers`, `method`, `pod`, `query_params` |
| `qualys_get_host` | Get detailed information about a specific host by ID or IP address. | optional `host_id`, `ip` |
| `qualys_get_host_detection_count` | Get a count of vulnerability detections matching filters. Quick summary without full detection data. | optional `ag_ids`, `ips`, `severities`, `status` |
| `qualys_get_scanner_appliance` | Get detailed information about a specific scanner appliance by ID. | **required** `appliance_id` |
| `qualys_get_vulnerability` | Get detailed information about a specific vulnerability by its QID (Qualys ID). Returns description, solution, CVSS score, and CVE mappings. | **required** `qid` |
| `qualys_ignore_vulnerability` | Ignore a vulnerability (by QID) on specific hosts so it won't appear in reports. Specify hosts by IPs, asset group IDs, or tag names. Up to 10 QIDs per request. | **required** `qids`<br />optional `ag_ids`, `comments`, `ips`, `tag_set_by`, `tag_set_include` |
| `qualys_launch_report` | Launch a report generation with specified template, output format (PDF/HTML/XML/CSV/DOCX), and target scope. | **required** `template_id`<br />optional `asset_group_ids`, `ips`, `output_format`, `report_title` |
| `qualys_launch_scan` | Launch a vulnerability scan against target IPs, asset groups, or tags with a specified scan title and option profile. | **required** `scan_title`<br />optional `asset_group_ids`, `ip`, `option_id`, `option_title`, `priority`, `scanner_name` |
| `qualys_list_activation_keys` | List Cloud Agent activation keys (provisioning inputs for agent installs). Uses the Qualys QPS REST API. Paginate while has_more is true by passing the previous response's last_id; stop when has_more is false. | optional `base_url`, `criteria`, `last_id`, `limit`, `pod`, `title_contains` |
| `qualys_list_agents` | List Cloud Agents with lifecycle state (version, status, last check-in, activation key, modules, OS). Filters by tag (default 'Cloud Agent') plus optional QPS criteria — prefer narrowing criteria over raising limit. | optional `base_url`, `criteria`, `last_id`, `limit`, `pod`, `tag_name` |
| `qualys_list_asset_group_scanners` | List scanner appliances assigned to an asset group. | **required** `group_id` |
| `qualys_list_asset_groups` | List asset groups with filtering by ID and title. Returns group definitions with IP sets and member info. | optional `id_min`, `ids`, `limit`, `title`, `truncation_limit` |
| `qualys_list_auth_records` | List authentication records by type. Defaults to 'windows' if no record_type is specified. Use record_type to query unix, ms_sql, or cisco records. | optional `details`, `id_max`, `id_min`, `ids`, `limit`, `record_type` |
| `qualys_list_compliance_exceptions` | List compliance exceptions (approved deviations from policy controls). | optional `id_max`, `id_min`, `limit`, `policy_id`, `status` |
| `qualys_list_compliance_policies` | List policy compliance policies with filtering. | optional `details`, `id_max`, `id_min`, `ids`, `limit`, `updated_after_datetime` |
| `qualys_list_compliance_scans` | List policy compliance scans with filtering by state and date range. | optional `launched_after_datetime`, `launched_before_datetime`, `limit`, `scan_ref`, `state` |
| `qualys_list_excluded_hosts` | List IPs currently excluded from scanning. | optional `limit` |
| `qualys_list_host_detections` | List vulnerability detections across hosts with filtering by IP, asset group, severity, QID, status (New/Active/Fixed/Re-Opened), and date range. Returns host records with their detected vulnerabilities. | optional `ag_ids`, `ag_titles`, `detection_updated_before`, `detection_updated_since`, `id_min`, `ids`, `ips`, `limit`, `qids`, `severities`, `show_qds`, `show_results`, `status`, `truncation_limit`, `vm_scan_date_after` |
| `qualys_list_hosts` | List host assets with filtering by IP, asset group, OS, tags, and scan dates. Returns host inventory with IPs, OS, DNS, and last scan info. | optional `ag_ids`, `ag_titles`, `details`, `id_min`, `ids`, `ips`, `limit`, `no_vm_scan_since`, `os_pattern`, `show_asset_id`, `show_tags`, `truncation_limit`, `use_tags`, `vm_scan_since` |
| `qualys_list_ignored_vulns` | List currently-ignored vulnerability detections (the audit counterpart to ignore_vulnerability/restore_vulnerability). | optional `ag_ids`, `id_min`, `ips`, `limit`, `qids`, `severities`, `truncation_limit` |
| `qualys_list_pc_option_profiles` | List Policy Compliance scan option profiles. Returns profile names, IDs, and configuration. | optional `limit`, `profile_id`, `title` |
| `qualys_list_pc_scan_schedules` | List scheduled Policy Compliance scan tasks. | optional `active`, `limit`, `schedule_id` |
| `qualys_list_reports` | List available reports with filtering by state (Running/Finished/Canceled/Errors). | optional `expires_before_datetime`, `limit`, `report_id`, `state` |
| `qualys_list_scanner_appliances` | List all scanner appliances in the subscription with status and configuration details. | optional `limit`, `output_mode` |
| `qualys_list_scans` | List vulnerability scans with filtering by state (Running/Finished/Error), type (On-Demand/Scheduled/API), target, and date range. | optional `launched_after_datetime`, `launched_before_datetime`, `limit`, `scan_ref`, `scan_type`, `show_ags`, `show_status`, `state`, `target` |
| `qualys_list_tags` | List asset tags using the Qualys QPS REST API. Returns tag definitions with IDs and names. | optional `limit`, `name` |
| `qualys_list_vm_option_profiles` | List VM scan option profiles. Returns profile names, IDs, and configuration. | optional `limit`, `profile_id`, `title` |
| `qualys_list_vm_scan_schedules` | List scheduled VM scan tasks. | optional `active`, `limit`, `schedule_id`, `show_cloud_details`, `show_notifications` |
| `qualys_manage_asset_group_ips` | Add, remove, or set the IP addresses of an existing asset group. action=add/remove edit the set incrementally and apply immediately. | **required** `group_id`, `action`, `ips`<br />optional `confirm` |
| `qualys_manage_asset_group_scanners` | Add, remove, or set scanner appliances for an asset group. | **required** `group_id`<br />optional `add_appliance_ids`, `remove_appliance_ids`, `set_appliance_ids` |
| `qualys_manage_compliance_policy_groups` | Add, remove, or set asset groups associated with a compliance policy. | **required** `policy_id`, `action`, `group_ids` |
| `qualys_manage_compliance_policy_tags` | Add, remove, or set asset tags associated with a compliance policy. Tags control which assets are evaluated against the policy. | **required** `policy_id`, `action`, `tag_set_include`<br />optional `tag_set_by` |
| `qualys_manage_scan` | Cancel, pause, or resume an in-progress vulnerability scan by its scan reference. | **required** `scan_ref`, `action` |
| `qualys_purge_host_data` | Purge scan data for specified hosts. WARNING: This is DESTRUCTIVE AND IRREVERSIBLE. Vulnerability data, scan history, and optionally compliance data will be permanently deleted. | **required** `ips`<br />optional `compliance_purge`, `confirm` |
| `qualys_qps_request` | Escape hatch: call any Qualys QPS REST API endpoint under /qps/rest/ (JSON) when no dedicated tool covers it. | **required** `path`<br />optional `base_url`, `body`, `extra_headers`, `method`, `pod`, `query_params` |
| `qualys_remove_excluded_hosts` | Remove IPs from the scan exclusion list, re-enabling them for scanning. | **required** `ips`<br />optional `comment` |
| `qualys_restore_vulnerability` | Restore (un-ignore) a previously ignored vulnerability on specific hosts, re-enabling it in reports. | **required** `qids`<br />optional `ag_ids`, `comments`, `ips`, `tag_set_by`, `tag_set_include` |
| `qualys_search_knowledge_base` | Search the Qualys vulnerability Knowledge Base by QID, CVE, or date range. | optional `cve`, `details`, `discovery_method`, `id_max`, `id_min`, `ids`, `is_patchable`, `last_modified_after`, `limit`, `published_after` |
| `qualys_tag_asset` | Add or remove a tag on a host asset by asset ID. Returns a trimmed acknowledgement, not the full asset record. | **required** `asset_id`, `tag_id`, `action` |
| `qualys_uninstall_agents` | Uninstall the Cloud Agent from one or more hosts by explicit asset ID. DESTRUCTIVE AND IRREVERSIBLE: the agent software is removed and reinstall requires re-deployment; uninstall completes asynchronously on each agent's next check-in. | **required** `asset_ids`<br />optional `base_url`, `confirm`, `pod` |

## Rapid7 InsightAppSec

12 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `rapid7-insightappsec_create_app` | Create a new InsightAppSec application to group scan targets | **required** `name`<br />optional `description` |
| `rapid7-insightappsec_get_app` | Get a single InsightAppSec application by its UUID | **required** `app_id` |
| `rapid7-insightappsec_get_scan` | Get details of a single scan by ID, including status and progress | **required** `scan_id` |
| `rapid7-insightappsec_get_scan_config` | Get a single scan configuration by its UUID | **required** `scan_config_id` |
| `rapid7-insightappsec_get_vulnerability` | Get full details for a single vulnerability by its UUID | **required** `vulnerability_id` |
| `rapid7-insightappsec_list_apps` | List InsightAppSec applications with optional name search and pagination | optional `index`, `name`, `size` |
| `rapid7-insightappsec_list_attack_templates` | List available attack templates that can be used in scan configurations | optional `index`, `size` |
| `rapid7-insightappsec_list_scan_configs` | List scan configurations, optionally filtered by application ID | optional `app_id`, `index`, `size` |
| `rapid7-insightappsec_list_scans` | List scans with optional filtering by application ID or status | optional `app_id`, `index`, `size`, `status` |
| `rapid7-insightappsec_search_vulnerabilities` | Search for vulnerabilities found by InsightAppSec scans. Use the query parameter with InsightAppSec search syntax, e.g. "vulnerability.scans.id='&lt;scan-uuid>'" to filter by scan, or "vulnerability.severity='HIGH'" to filter by severity. | optional `app_id`, `index`, `query`, `scan_id`, `severity`, `size` |
| `rapid7-insightappsec_start_scan` | Start a new DAST scan using an existing scan configuration | **required** `scan_config_id` |
| `rapid7-insightappsec_stop_scan` | Submit a control action (stop, pause, or resume) to a scan | **required** `scan_id`<br />optional `action` |

## Rapid7 InsightCloudSec

12 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `rapid7-insightcloudsec_get_clouds_summary` | Get a summary report across all connected cloud accounts: total cloud count, breakdown by cloud provider (AWS/Azure/GCP/etc.), and resource counts by resource type per cloud. | — |
| `rapid7-insightcloudsec_get_insight` | Get the full definition of a single Insight, including its filters, applicable resource types, severity, and metadata. | **required** `insight_id`<br />optional `insight_source` |
| `rapid7-insightcloudsec_get_resource` | Get full details for a single InsightCloudSec resource by its resource ID, including normalized properties, tags, dependencies (VPCs, subnets, encryption keys), and noncompliance status. | **required** `resource_id` |
| `rapid7-insightcloudsec_get_resource_sources` | Get the raw cloud provider source documents that InsightCloudSec harvested for a resource (e.g. the original AWS DescribeInstances response). | **required** `resource_id` |
| `rapid7-insightcloudsec_list_applications` | List Applications — user-defined groupings of cloud resources used for scoping (e.g. by business unit, environment, or criticality). Returns each Application's name, category, resource count, account count, and cloud providers. | optional `order_by`, `page`, `page_size`, `search` |
| `rapid7-insightcloudsec_list_cloud_findings` | List Insight findings (policy violations) for an entire cloud account. Use to check the compliance posture of a specific cloud. Use 'cursor' from the previous response for pagination. | **required** `organization_service_id`<br />optional `cursor` |
| `rapid7-insightcloudsec_list_clouds` | List all cloud accounts (AWS, Azure, GCP, OCI, Alibaba, etc.) configured in InsightCloudSec, including their connection status, account IDs, harvesting strategy, and resource counts. | — |
| `rapid7-insightcloudsec_list_filter_registry` | List every query filter available for use with search_resources. Returns each filter's name and the shape of its config object — use this to discover what filters can be applied when searching resources. | — |
| `rapid7-insightcloudsec_list_insight_packs` | List Insight Packs — collections of Insights grouped by compliance framework (CIS, PCI DSS, NIST, SOC 2, HIPAA, etc.) or by Rapid7-curated categories. Use to discover available compliance frameworks and their pack IDs. | — |
| `rapid7-insightcloudsec_list_insights` | List all available Insights (compliance checks and security policies) in InsightCloudSec. Optionally filter by labels (e.g. 'cis controls'), Insight packs, or resource types. | optional `detail`, `labels`, `pack_ids`, `resource_types` |
| `rapid7-insightcloudsec_list_resource_violations` | List all Insight findings (policy violations) for a single resource. Returns each matching Insight with its severity, description, and the date it was identified. | **required** `resource_id` |
| `rapid7-insightcloudsec_search_resources` | Search InsightCloudSec's normalized resource inventory across all connected cloud accounts. | optional `badge_filter_operator`, `badges`, `cursor`, `filters`, `insight`, `limit`, `offset`, `scopes`, `selected_resource_type`, `tags` |

## Rapid7 InsightVM

18 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `rapid7-insightvm_control_scan` | Send a control action to a scan: 'pause' (running -> paused), 'resume' (paused -> running), 'stop' (running or paused -> stopped; non-reversible). | **required** `scan_id`, `action` |
| `rapid7-insightvm_generate_report` | Trigger generation of a new report instance from an existing report config. | **required** `report_id`<br />optional `report_format` |
| `rapid7-insightvm_get_asset` | Get a single asset's full detail by ID: hostnames, IPs, OS, MAC addresses, installed software, configurations, services, user accounts, risk score, and vulnerability counts by severity. | **required** `asset_id` |
| `rapid7-insightvm_get_scan` | Get a single scan's status: state (e.g. running, finished, paused, stopped, aborted), vulnerability counts (critical/severe/moderate), discovered asset count, duration, and engine. | **required** `scan_id` |
| `rapid7-insightvm_get_site` | Get a single site's detail by ID. | **required** `site_id` |
| `rapid7-insightvm_get_vulnerability` | Get full detail for a single vulnerability: CVSS v2/v3 vectors, PCI severity, CVE references, exploit and malware-kit data, categorical tags, and human-readable description. | **required** `vulnerability_id` |
| `rapid7-insightvm_list_asset_groups` | List asset groups defined on the console (static or dynamic): group ID, name, type, asset count, and risk-score aggregate. | optional `page`, `size` |
| `rapid7-insightvm_list_asset_vulnerabilities` | List vulnerabilities affecting a specific asset. Returns the vulnerability ID, first/most-recent observation, port/protocol context, exception status, and proof string. | **required** `asset_id`<br />optional `page`, `size` |
| `rapid7-insightvm_list_assets` | List all assets known to the InsightVM console with paginated results. Returns asset summaries including hostnames, IPs, OS fingerprint, risk score, and last-scanned timestamp. | optional `page`, `size`, `sort` |
| `rapid7-insightvm_list_reports` | List all report configurations defined on the console: report ID, name, format, template, owner, and scope. Use generate_report with one of these IDs to trigger a fresh report instance. | optional `page`, `size` |
| `rapid7-insightvm_list_scans` | List scans across the console with optional active-only filter. Returns scan ID, site, status, start/end times, duration, engine, and discovered-vulnerability counts. | optional `active_only`, `page`, `size` |
| `rapid7-insightvm_list_sites` | List all scan sites configured on the InsightVM console: site names, scan template, scan engine, target asset count, and last-scan summary. | optional `page`, `size` |
| `rapid7-insightvm_list_tags` | List tags configured on the console (custom, location, owner, criticality, etc.). Tags drive dynamic asset-group membership and reporting scope. | optional `page`, `size` |
| `rapid7-insightvm_list_vulnerabilities` | List vulnerabilities in the InsightVM vulnerability catalog. Optional severity filter narrows results to Critical / Severe / Moderate. Returns paged summaries with CVSS scores, exploit and malware-kit availability flags. | optional `page`, `severity`, `size` |
| `rapid7-insightvm_list_vulnerability_exceptions` | List vulnerability exceptions (accepted-risk decisions) on the console: exception ID, vulnerability, scope, reason, expiration, submitter, and approval status. | optional `page`, `size` |
| `rapid7-insightvm_list_vulnerability_solutions` | List remediation solutions for a vulnerability: patch references, configuration changes, workarounds, and the estimated time / effort required. Use to inform a remediation playbook. | **required** `vulnerability_id`<br />optional `page`, `size` |
| `rapid7-insightvm_search_assets` | Search assets using InsightVM filter expressions. Supply a list of {field, operator, value} filters and a match mode ('all' for AND, 'any' for OR). | **required** `filters`<br />optional `match`, `page`, `size` |
| `rapid7-insightvm_start_site_scan` | Start a new scan against a site. Optionally override the scan engine, scan template, hosts (IP / hostname list), or assign a human-readable scan name. Returns the new scan ID. | **required** `site_id`<br />optional `engine_id`, `hosts`, `name`, `template_id` |

## Rapid7 InsightVM Cloud

10 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `rapid7-insightvm-cloud_get_asset` | Get a single asset's full detail by ID: hostnames, IPs, OS, MAC addresses, installed software, services, risk score, and vulnerability counts by severity. | **required** `asset_id` |
| `rapid7-insightvm-cloud_get_scan` | Get a single scan's status: state (e.g. running, finished, paused, stopped, aborted), vulnerability counts (critical/severe/moderate), discovered asset count, duration, and engine. | **required** `scan_id` |
| `rapid7-insightvm-cloud_get_site` | Get a single site's detail by ID: name, description, scan template, scan engine, target asset count, vulnerability counts, and last-scan summary. | **required** `site_id` |
| `rapid7-insightvm-cloud_get_vulnerability` | Get full detail for a single vulnerability: CVSS v2/v3 vectors, PCI severity, CVE references, exploit and malware-kit data, categorical tags, and human-readable description. | **required** `vulnerability_id` |
| `rapid7-insightvm-cloud_list_asset_vulnerabilities` | List vulnerabilities affecting a specific asset. Returns the vulnerability ID, first/most-recent observation, port/protocol context, and proof string. Use get_vulnerability for the full vulnerability description and severity. | **required** `asset_id`<br />optional `page`, `size` |
| `rapid7-insightvm-cloud_list_assets` | List assets known to the InsightVM Cloud platform with paginated results. Returns asset summaries including hostnames, IPs, OS fingerprint, risk score, and last-scanned timestamp. | optional `page`, `size`, `sort` |
| `rapid7-insightvm-cloud_list_scan_engines` | List scan engines available to the Cloud platform: engine ID, name, status, address, port, last-refresh time, and engine pool membership. Useful for confirming which engines are online before correlating recent scan results. | optional `page`, `size` |
| `rapid7-insightvm-cloud_list_scans` | List scans across the Cloud platform with optional active-only filter. Returns scan ID, site, status, start/end times, duration, engine, and discovered-vulnerability counts. | optional `active_only`, `page`, `size` |
| `rapid7-insightvm-cloud_list_sites` | List all scan sites configured on the InsightVM Cloud platform: site names, scan template, scan engine, target asset count, and last-scan summary. | optional `page`, `size` |
| `rapid7-insightvm-cloud_list_vulnerabilities` | List vulnerabilities in the InsightVM Cloud catalog. Optional severity filter narrows results to Critical / Severe / Moderate. Returns paged summaries with CVSS scores, exploit and malware-kit availability flags. | optional `page`, `severity`, `size` |

## Snyk

8 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `snyk_get_api_security_finding` | Retrieve a single Snyk API Security finding by id. Note: endpoint shape is best-effort and may need adjustment against real tenant. | **required** `org_id`, `finding_id` |
| `snyk_get_issue` | Retrieve a single Snyk security issue by id. Returns full detail including CWE/CVE classes, problem references, coordinate paths, and risk scoring. | **required** `org_id`, `issue_id` |
| `snyk_get_organization` | Retrieve a single Snyk organization by id. | **required** `org_id` |
| `snyk_get_project` | Retrieve a single Snyk project by id within an organization. | **required** `org_id`, `project_id` |
| `snyk_list_api_security_findings` | List Snyk API Security findings in an organization — API risk discoveries from Snyk's API Security product. Filter by severity or status. Cursor-paginated. | **required** `org_id`<br />optional `ending_before`, `limit`, `severity`, `starting_after`, `status` |
| `snyk_list_issues` | List Snyk security issues (vulnerabilities, license issues, code issues) in an organization. Scope to a single project by passing project_id. Filter by severity, status, type, or ignored state. Cursor-paginated. | **required** `org_id`<br />optional `effective_severity_levels`, `ending_before`, `ignored`, `limit`, `project_id`, `starting_after`, `statuses`, `types` |
| `snyk_list_organizations` | List Snyk organizations the authenticated token can access. Cursor-paginated via starting_after / ending_before. | optional `ending_before`, `limit`, `starting_after` |
| `snyk_list_projects` | List Snyk projects in an organization. Optional filters: origins (e.g. github, gitlab, cli), types (e.g. npm, maven, docker), target_id. Cursor-paginated. | **required** `org_id`<br />optional `ending_before`, `limit`, `origins`, `starting_after`, `target_id`, `types` |

## Tenable Vulnerability Management

16 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `tenable-vulnerability-management_check_asset_export_status` | Poll the status of a running asset export job. Indicates completion % or chunk availability for Nessus-scanned assets. | **required** `export_job_id` |
| `tenable-vulnerability-management_check_vuln_export_status` | Poll the status of a running vulnerability export job. Indicates completion % or chunk availability for Nessus findings. | **required** `export_job_id` |
| `tenable-vulnerability-management_get_asset_activity_log` | Get activity log for a Nessus-scanned asset showing discovery, scans, attribute changes, tagging events, updates, and source information over time. | **required** `asset_uuid` |
| `tenable-vulnerability-management_get_asset_details` | Get detailed information for a specific Nessus-scanned asset including vulnerabilities, tags, installed software, cloud metadata (AWS/Azure/GCP), and Lumin metrics. | **required** `asset_uuid` |
| `tenable-vulnerability-management_get_asset_export_chunk` | Retrieve a chunk of exported asset data. Each chunk contains Nessus-scanned asset records with details and tags. | **required** `export_job_id`, `chunk_id` |
| `tenable-vulnerability-management_get_asset_vuln_outputs` | Retrieve Nessus plugin outputs (evidence details) for a specific vulnerability on a specific asset. Shows the proof of vulnerability occurrence. | **required** `asset_id`, `plugin_id` |
| `tenable-vulnerability-management_get_plugin_details` | Get detailed Nessus plugin information including description, solution, CVSS scores, VPR, exploit availability, and references. Supports filtering to scope results. | **required** `plugin_id`<br />optional `date_range`, `filter_search_type`, `filters` |
| `tenable-vulnerability-management_get_vuln_export_chunk` | Retrieve a chunk of exported vulnerability data. Once an export is ready, fetch Nessus vulnerabilities. | **required** `export_job_id`, `chunk_id` |
| `tenable-vulnerability-management_list_asset_filters` | List available Nessus asset filters with their names, operators, and validation rules. Use this to discover valid filter names and operators for the list_assets and list_assets_with_vulnerabilities tools. | — |
| `tenable-vulnerability-management_list_asset_vulnerabilities` | List up to 5,000 Nessus-detected vulnerabilities found on a specific asset with summary info (plugin ID, severity, VPR, state). Supports filtering. | **required** `asset_id`<br />optional `date_range`, `filter_search_type`, `filters` |
| `tenable-vulnerability-management_list_assets` | List up to 5,000 Nessus-scanned assets with summary info (IP addresses, OS, agent status, sources). Supports filtering. For larger datasets, use asset export tools. | optional `all_fields`, `date_range`, `filter_search_type`, `filters` |
| `tenable-vulnerability-management_list_assets_with_vulnerabilities` | List up to 5,000 Nessus-scanned assets that have vulnerabilities, showing each asset with severity counts (info/low/medium/high/critical). | optional `date_range`, `filter_search_type`, `filters` |
| `tenable-vulnerability-management_list_vulnerabilities` | List up to 5,000 Nessus-detected vulnerabilities with summary info (plugin ID, severity, VPR, state). Limited to 450 days of data. For larger exports, use vuln export tools. | optional `date_range`, `filter_search_type`, `filters` |
| `tenable-vulnerability-management_list_vulnerability_filters` | List available Nessus vulnerability filters with their names, operators, and validation rules. Use this to discover valid filter names and operators for the list_vulnerabilities, get_plugin_details, and list_asset_vulnerabilities tools. | — |
| `tenable-vulnerability-management_start_asset_export` | Initiate an export of assets with tags and metadata. Includes assets discovered by Nessus scans. | optional `chunk_size`, `filters`, `include_open_ports` |
| `tenable-vulnerability-management_start_vuln_export` | Initiate an export of vulnerabilities matching criteria. Starts a Tenable vuln export job. Exports Nessus scan findings. | optional `chunk_size`, `filters`, `since`, `state` |

## Traceable

4 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `traceable_api_spec_conformance_results` | Query API spec conformance results — shadow endpoints, orphan endpoints, parameter diffs, and summaries. | **required** `spec_id`, `query_type`<br />optional `limit`, `offset` |
| `traceable_entities` | Query Traceable entities (API, SERVICE, BACKEND, DOMAIN, ACTOR). Always returns id, type, and labels. Optionally include metrics (provide metric_key), attributes (provide attribute_key), or edges (provide edge_neighbor_type). | optional `attribute_key`, `between`, `edge_neighbor_scope`, `edge_neighbor_type`, `edge_type`, `entity_type`, `filter_by`, `include_inactive`, `limit`, `metric_key`, `offset`, `order_by`, `scope`, `space` |
| `traceable_parameter_insights` | Query API parameter insights — names, types, PII classification, and change tracking. | optional `aggregation_key`, `aggregation_type`, `entity_type`, `filter_by`, `group_by`, `limit`, `offset`, `order_by`, `selection_fields` |
| `traceable_threat_activity` | Query threat activity records. Always returns selection fields (default: ID, TYPE, SEVERITY_LEVEL, ACTIVITY_STATUS, IS_BLOCKED, ACTOR_ENTITY_ID, SERVICE_NAME, API_NAME, CATEGORIES, START_TIME_MILLIS, LAST_SEEN_MILLIS, EVENTS_COUNT). | optional `aggregation_key`, `aggregation_type`, `filter_by`, `group_by`, `limit`, `offset`, `order_by`, `selection_fields`, `unnest` |

## Wiz (Client Credentials)

1 tool. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `wiz-cc_list_all_vulnerability_findings` | Return a COMPLETE, deterministic set of Wiz vulnerability findings by walking the cursor server-side, instead of relying on the model to paginate. Repeated identical queries return identical counts. | optional `fields`, `filters`, `max_results`, `order_by_direction`, `order_by_field`, `page_size`, `source_tool` |

---

## Identity and secrets

Source: https://docs.kindo.ai/reference/tool-catalog/identity-secrets/

:::note[Beta]
The tool catalog is in beta and is a point-in-time snapshot of the integration inventory, so an entry can differ from what your organization sees in product.
:::

Directory, governance, and secret-management systems an agent can inspect and change. 10 integrations, 274 tools.

Tool names below are the fully qualified names an agent sees once the integration is connected. Where an integration offers more than one connection, the names shown use the primary connection's prefix; connecting through another variant prefixes its tools with that variant's own integration ID instead. See [Tool Catalog](/reference/tool-catalog/) for how tools are granted and named.

## Cisco Secure Access

22 tools. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cisco-secure-access_create_application_list` | Create a new application list for grouping cloud applications in policies | **required** `name`<br />optional `application_ids` |
| `cisco-secure-access_create_destination_list` | Create a new destination list (block or allow list) with optional initial destinations | **required** `name`<br />optional `destinations`, `is_global` |
| `cisco-secure-access_create_internal_network` | Create a new internal network with IP address, prefix length, and optional site/tunnel association | **required** `name`, `ip_address`, `prefix_length`<br />optional `site_id`, `tunnel_id` |
| `cisco-secure-access_create_private_resource` | Create a new private resource for ZTNA access with addresses and protocols | **required** `name`, `addresses`<br />optional `description`, `protocols` |
| `cisco-secure-access_delete_application_list` | Delete an application list by ID | **required** `application_list_id` |
| `cisco-secure-access_delete_destination_list` | Delete a destination list by ID | **required** `destination_list_id` |
| `cisco-secure-access_delete_private_resource` | Delete a private resource by ID | **required** `resource_id` |
| `cisco-secure-access_get_activity` | Get security activity events (DNS, proxy, firewall, ZTNA, intrusion) within a time range with filtering | **required** `from_time`, `to_time`<br />optional `categories`, `domains`, `ip`, `limit`, `offset`, `verdict` |
| `cisco-secure-access_get_application_list` | Get a specific application list by ID including its member applications | **required** `application_list_id` |
| `cisco-secure-access_get_destination_list` | Get a specific destination list by ID including its metadata and destination count | **required** `destination_list_id` |
| `cisco-secure-access_get_dns_activity` | Get DNS-specific activity events with domain, category, and verdict filtering within a time range | **required** `from_time`, `to_time`<br />optional `categories`, `domains`, `limit`, `offset`, `verdict` |
| `cisco-secure-access_get_internal_network` | Get a specific internal network by ID including its IP range and site association | **required** `network_id` |
| `cisco-secure-access_get_private_resource` | Get a specific private resource by ID including its addresses, protocols, and configuration | **required** `resource_id` |
| `cisco-secure-access_investigate_domain` | Get domain security status, risk categorization, and content categories for a single domain | **required** `domain` |
| `cisco-secure-access_investigate_domains_bulk` | Bulk domain lookup — get security status and categorization for up to 1000 domains at once | **required** `domains` |
| `cisco-secure-access_list_application_lists` | List cloud application lists used to group apps for policy enforcement | optional `limit`, `page` |
| `cisco-secure-access_list_destination_lists` | List all Cisco Secure Access destination lists (block/allow lists of domains, URLs, and IPs) with pagination | optional `limit`, `page` |
| `cisco-secure-access_list_internal_networks` | List internal networks (subnets) configured in Cisco Secure Access | optional `limit`, `page` |
| `cisco-secure-access_list_private_resources` | List private resources/applications configured for ZTNA (Zero Trust Network Access) | optional `limit`, `page` |
| `cisco-secure-access_list_roaming_computers` | List enrolled roaming computers/devices with their DNS and internet security status | optional `limit`, `page` |
| `cisco-secure-access_manage_destinations` | Add or remove destinations (domains/URLs/IPs) in a destination list. Use action='add' with destinations, or action='remove' with destination_ids | **required** `destination_list_id`, `action`<br />optional `destination_ids`, `destinations` |
| `cisco-secure-access_update_destination_list` | Update a destination list's name | **required** `destination_list_id`<br />optional `name` |

## CyberArk Privilege Cloud

30 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cyberark-privilege-cloud_activate_platform` | Activate a target platform so it can be used for new accounts. | **required** `platform_id` |
| `cyberark-privilege-cloud_add_safe_member` | Grant a user, group, or role access to a safe with specific permissions. | **required** `safe_name`, `member_name`, `permissions`<br />optional `member_type` |
| `cyberark-privilege-cloud_change_account_password` | Initiate a CPM-managed password change for an account. The CPM will generate and set a new password on the target. | **required** `account_id` |
| `cyberark-privilege-cloud_create_account` | Provision a new privileged account in CyberArk. Requires a safe name and platform ID at minimum. | **required** `safe_name`, `platform_id`<br />optional `address`, `name`, `properties`, `secret`, `secret_type`, `user_name` |
| `cyberark-privilege-cloud_create_safe` | Create a new safe in CyberArk for storing privileged accounts. | **required** `safe_name`<br />optional `description`, `managing_cpm`, `number_of_days_retention` |
| `cyberark-privilege-cloud_deactivate_platform` | Deactivate a target platform to prevent it from being assigned to new accounts. | **required** `platform_id` |
| `cyberark-privilege-cloud_delete_account` | Delete a privileged account from CyberArk by its unique ID. | **required** `account_id` |
| `cyberark-privilege-cloud_delete_platform` | Delete a target platform from CyberArk by its numeric ID. | **required** `platform_id` |
| `cyberark-privilege-cloud_delete_safe` | Delete a safe from CyberArk by its name. | **required** `safe_name` |
| `cyberark-privilege-cloud_duplicate_platform` | Duplicate an existing target platform with a new name. | **required** `platform_id`, `name`<br />optional `description` |
| `cyberark-privilege-cloud_export_platform` | Export a platform as a base64-encoded ZIP package. | **required** `platform_id` |
| `cyberark-privilege-cloud_get_account` | Get full details of a privileged account by its unique ID. | **required** `account_id` |
| `cyberark-privilege-cloud_get_platform` | Get full details of a platform by its ID. | **required** `platform_id` |
| `cyberark-privilege-cloud_get_safe` | Get full details of a safe by its name. | **required** `safe_name` |
| `cyberark-privilege-cloud_get_safe_member` | Get details of a specific member of a safe. | **required** `safe_name`, `member_name` |
| `cyberark-privilege-cloud_get_session` | Get full details of a privileged session recording by its ID. | **required** `session_id` |
| `cyberark-privilege-cloud_import_platform` | Import a platform from a ZIP package by reference. Pass `source_url`: a short-lived signed download URL minted by the `mint_upload_url` tool. The server fetches the ZIP bytes from `source_url` (binary-safe) and imports the platform. | **required** `source_url` |
| `cyberark-privilege-cloud_list_accounts` | List and search privileged accounts in CyberArk. Supports filtering by safe name, username, address, and platform. | optional `filter_query`, `limit`, `offset`, `safe_name`, `search` |
| `cyberark-privilege-cloud_list_live_sessions` | List currently active (live) privileged sessions. | optional `limit`, `offset`, `search` |
| `cyberark-privilege-cloud_list_platforms` | List platforms available in CyberArk with optional search and type filter. | optional `platform_type`, `search` |
| `cyberark-privilege-cloud_list_safe_members` | List all members (users, groups, roles) with access to a safe. | **required** `safe_name`<br />optional `filter_query` |
| `cyberark-privilege-cloud_list_safes` | List safes in CyberArk with optional search and pagination. | optional `limit`, `offset`, `search` |
| `cyberark-privilege-cloud_list_session_activities` | List all activities (commands, keystrokes) within a session recording. | **required** `session_id` |
| `cyberark-privilege-cloud_list_sessions` | List privileged session recordings with optional search and pagination. | optional `limit`, `offset`, `search` |
| `cyberark-privilege-cloud_reconcile_account_password` | Reconcile (sync) the password between CyberArk and the target system. Used when passwords are out of sync. | **required** `account_id` |
| `cyberark-privilege-cloud_remove_safe_member` | Remove a member from a safe, revoking all their permissions. | **required** `safe_name`, `member_name` |
| `cyberark-privilege-cloud_update_account` | Update an existing account using JSON Patch operations (RFC 6902). Example: [{'op': 'replace', 'path': '/address', 'value': '10.0.0.1'}] | **required** `account_id`, `operations` |
| `cyberark-privilege-cloud_update_safe` | Update an existing safe's configuration (description, CPM, retention). | **required** `safe_name`<br />optional `description`, `managing_cpm`, `number_of_days_retention` |
| `cyberark-privilege-cloud_update_safe_member` | Update a safe member's permissions. | **required** `safe_name`, `member_name`, `permissions` |
| `cyberark-privilege-cloud_verify_account_password` | Verify that the password stored in CyberArk matches the actual password on the target system. | **required** `account_id` |

## Delinea Secret Server

10 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `delinea-secret-server_change_secret_password` | Rotate (change) the password on a secret. If `new_password` is omitted, Secret Server generates one according to the secret's password policy. | **required** `secret_id`<br />optional `new_password` |
| `delinea-secret-server_checkin_secret` | Check in a previously checked-out secret, ending exclusive access so other users can use it. Optionally force check-in (requires the 'Force Check In' permission). | **required** `secret_id`<br />optional `comment`, `force_check_in` |
| `delinea-secret-server_checkout_secret` | Check out a secret that requires exclusive checkout before its credentials can be used. After checkout, call get_secret to read the value, then checkin_secret when finished. | **required** `secret_id` |
| `delinea-secret-server_create_secret` | Create a new secret in a folder from a secret template. `items` is the list of template field values, e.g. [{'fieldName': 'Password', 'itemValue': '...', 'slug': 'password'}]. | **required** `name`, `folder_id`, `secret_template_id`, `items`<br />optional `site_id` |
| `delinea-secret-server_get_folder` | Get details of a folder by its ID, including child folders. | **required** `folder_id` |
| `delinea-secret-server_get_secret` | Retrieve a secret by ID, including its field values (e.g. username/password). For secrets that require a comment to view, pass `comment`. Use get_secret_summary to inspect metadata without exposing field values. | **required** `secret_id`<br />optional `comment` |
| `delinea-secret-server_get_secret_summary` | Get non-sensitive summary metadata for a secret (name, folder, template, checkout/approval status) without returning field values. | **required** `secret_id` |
| `delinea-secret-server_search_folders` | Search and browse folders in Delinea Secret Server by free text and/or parent folder. | optional `only_root_folders`, `parent_folder_id`, `search_text`, `skip`, `take` |
| `delinea-secret-server_search_secrets` | Search and list secrets in Delinea Secret Server by free text and/or folder. Returns secret metadata (id, name, folder), not field values — use get_secret to read the actual credentials. | optional `folder_id`, `include_subfolders`, `search_text`, `skip`, `take` |
| `delinea-secret-server_update_secret` | Update an existing secret. Pass the full secret object (as returned by get_secret) with your modifications applied — Secret Server expects the complete object on update (GET, modify, then update). | **required** `secret_id`, `secret` |

## Doppler

14 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `doppler_create_config` | Create a new branch config under a project environment. Requires a Personal or CLI token (Service Tokens cannot create configs). | **required** `project`, `environment`, `name` |
| `doppler_create_environment` | Create a new environment in a project (e.g., development, staging, production). Requires a Personal or CLI token (Service Tokens cannot create environments). | **required** `project`, `name`, `slug`<br />optional `personal_configs` |
| `doppler_create_project` | Create a new project in the Doppler workspace. Requires a Personal or CLI token (Service Tokens are scoped to a single config and cannot create projects). | **required** `name`<br />optional `description` |
| `doppler_delete_secret` | Delete a single secret from a config by name. Works with Service Tokens scoped to the target config. | **required** `project`, `config`, `name` |
| `doppler_get_activity_log` | Get details of a single activity log entry by ID | **required** `log` |
| `doppler_get_config` | Get details of a single config by project and config name | **required** `project`, `config` |
| `doppler_get_project` | Get details of a single project by its slug identifier | **required** `project` |
| `doppler_get_secret` | Get a single secret's value and metadata by name | **required** `project`, `config`, `name` |
| `doppler_list_activity_logs` | List activity logs for the workspace with optional pagination | optional `fetch_all`, `page`, `per_page` |
| `doppler_list_configs` | List configs for a project, optionally filtered by environment | **required** `project`<br />optional `environment`, `fetch_all`, `page`, `per_page` |
| `doppler_list_environments` | List all environments for a given project (e.g., development, staging, production) | **required** `project` |
| `doppler_list_projects` | List all projects in the Doppler workspace with optional pagination | optional `fetch_all`, `page`, `per_page` |
| `doppler_list_secrets` | List all secrets in a config. Returns an object with a 'secrets' array; each entry includes the secret name alongside the fields returned by the Doppler API (typically raw value, computed value, and note). | **required** `project`, `config`<br />optional `include_dynamic_secrets`, `include_managed_secrets` |
| `doppler_set_secret` | Set a single secret in a config (upsert). Works with Service Tokens scoped to the target config. | **required** `project`, `config`, `name`, `value` |

## Microsoft Entra ID

34 tools. Available as 4 connections: Microsoft Entra ID (OAuth 2.0), Microsoft Entra ID (Application) (OAuth 2.0 client credentials), Microsoft Entra ID (GCC High) (OAuth 2.0), Microsoft Entra ID (GCC High, Application) (OAuth 2.0 client credentials).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-entra-id_disable_user_account` | Disable a user account so the user cannot sign in. Primary containment action for a compromised account; reverse it with enable_user_account. | **required** `user_id` |
| `microsoft-entra-id_enable_user_account` | Enable a previously disabled user account so the user can sign in again. | **required** `user_id` |
| `microsoft-entra-id_evaluate_conditional_access` | Answer what conditional access would do for a sign-in that has not happened: the What If tool. Requires who is signing in — pass user_id (an object id or userPrincipalName) or service_principal_id. | optional `applied_policies_only`, `authentication_context_value`, `client_app_type`, `country`, `device_platform`, `include_applications`, `ip_address`, `service_principal_id`, `service_principal_risk_level`, `sign_in_risk_level`, `user_action`, `user_id`, `user_risk_level` |
| `microsoft-entra-id_get_authentication_sla_attainment` | Read Microsoft Entra authentication SLA attainment by calendar month for this tenant. | — |
| `microsoft-entra-id_get_conditional_access_impact_summary` | Count what conditional access actually did over a time window: how many sign-ins each policy allowed, blocked, or did not apply to, including report-only policies. | optional `application`, `days_back`, `group_by`, `max_records`, `policy_ids`, `user_principal_name` |
| `microsoft-entra-id_get_conditional_access_policy` | Get one conditional access policy by id, including its conditions and grant controls. Locations and authentication strengths appear as GUIDs; resolve them with list_named_locations and list_authentication_strengths. | **required** `policy_id`<br />optional `select` |
| `microsoft-entra-id_get_directory_audit_details` | Get one directory audit entry by id, with its full target-resource list. | **required** `directory_audit_id`<br />optional `select` |
| `microsoft-entra-id_get_directory_objects_by_ids` | Resolve directory object ids to the objects themselves, in one call, for ids that came back from audit logs or group listings. | **required** `ids`<br />optional `types` |
| `microsoft-entra-id_get_directory_role` | Get one directory role by object id or role template id. Only roles activated in the tenant are returned. | optional `role_id`, `role_template_id`, `select` |
| `microsoft-entra-id_get_group` | Get one group by object id. Use list_groups to find an id from a name. | **required** `group_id`<br />optional `select` |
| `microsoft-entra-id_get_sign_in_details` | Get one sign-in event by id, including its status, device and location detail. | **required** `sign_in_id`<br />optional `select` |
| `microsoft-entra-id_get_user` | Get one directory user by object id or user principal name. Use list_users to find an id first when only a name is known. | **required** `user_id`<br />optional `select` |
| `microsoft-entra-id_get_user_inplace_hold_status` | Get the in-place hold policies applied to a user, for legal hold and retention checks. | **required** `user_id` |
| `microsoft-entra-id_get_user_registration_details` | Get one user's registered authentication methods and capabilities. | **required** `user_id` |
| `microsoft-entra-id_get_users_registered_by_method` | Count users registered for each authentication method across the tenant, scoped by user type and directory role — for example how many privileged admins have registered a phishing-resistant method. | optional `included_user_roles`, `included_user_types` |
| `microsoft-entra-id_list_adfs_application_activity` | List AD FS relying parties with their sign-in volume and whether each can be migrated to Microsoft Entra ID, for planning an AD FS migration. Aggregated over the given period. | optional `period`, `skip_token` |
| `microsoft-entra-id_list_app_credential_sign_in_activity` | List each application credential — secret, certificate, or federated identity credential — with when it was last used to sign in and when it expires, so stale and expiring credentials can be found. | optional `filter_query`, `order_by`, `skip_token`, `top` |
| `microsoft-entra-id_list_application_sign_in_summary` | List per-application sign-in counts with their success or failure status, to see which applications users are actually signing in to and where sign-ins are erroring. | optional `filter_query`, `order_by`, `skip_token`, `top` |
| `microsoft-entra-id_list_authentication_strengths` | List authentication strength policies and the method combinations each accepts. Conditional access grant controls reference these by GUID, so call this to read what a policy actually requires. | optional `filter_query`, `order_by`, `select`, `top` |
| `microsoft-entra-id_list_conditional_access_policies` | List conditional access policies with their state (enabled, disabled, or report-only). | optional `filter_query`, `order_by`, `select`, `skip_token`, `top` |
| `microsoft-entra-id_list_directory_audits` | List directory audit entries — who changed what in the directory. Narrow with a filter such as 'activityDateTime ge 2026-08-01T00:00:00Z' before widening. When has_more is true, pass next_skip_token back as skip_token. | optional `filter_query`, `order_by`, `select`, `skip_token`, `top` |
| `microsoft-entra-id_list_directory_recommendations` | List Microsoft Entra recommendations for this tenant — best-practice findings and Identity Secure Score improvements, with their status and priority. Filter on status to see only what is still open. | optional `filter_query`, `order_by`, `skip_token`, `top` |
| `microsoft-entra-id_list_directory_role_members` | List the principals holding a directory role, identified by object id or role template id. | optional `role_id`, `role_template_id`, `select` |
| `microsoft-entra-id_list_directory_roles` | List the directory roles activated in the tenant. A role that has never been activated does not appear. | optional `expand`, `filter_query`, `select` |
| `microsoft-entra-id_list_group_members` | List a group's members. Members can be users, groups, devices or service principals; set member_type to narrow to one kind. | **required** `group_id`<br />optional `count`, `expand`, `filter_query`, `member_type`, `order_by`, `search`, `select`, `skip_token`, `top` |
| `microsoft-entra-id_list_group_owners` | List a group's owners. Set owner_type to narrow to one directory kind. | **required** `group_id`<br />optional `count`, `expand`, `filter_query`, `owner_type`, `search`, `select`, `skip_token`, `top` |
| `microsoft-entra-id_list_groups` | List groups in the directory. When has_more is true, pass next_skip_token back as skip_token. | optional `count`, `display_name_starts_with`, `expand`, `filter_query`, `mail_enabled`, `mail_nickname_starts_with`, `order_by`, `search`, `security_enabled`, `select`, `skip_token`, `top` |
| `microsoft-entra-id_list_named_locations` | List named locations (IP ranges and country lists). Conditional access policies reference these by GUID, so call this to read what a policy's location conditions actually mean. | optional `filter_query`, `order_by`, `select`, `skip_token`, `top` |
| `microsoft-entra-id_list_provisioning_object_summary` | List provisioning events, which record identities synchronised into and out of the directory. When has_more is true, pass next_skip_token back as skip_token. | optional `count`, `filter_query`, `order_by`, `skip_token`, `top` |
| `microsoft-entra-id_list_service_principal_sign_in_activity` | List when each service principal last signed in, so unused ones can be found and retired. Covers delegated and app-only flows, as client and as resource. Filter with `app_id eq '<guid>'` for one application. | optional `filter_query`, `order_by`, `skip_token`, `top` |
| `microsoft-entra-id_list_sign_ins` | List sign-in log entries. Graph charges for the span the query covers, so a large top over a wide period is slow enough to time out: keep top small, or bound the period with filter_query, and do not do neither. | optional `count`, `filter_query`, `select`, `skip_token`, `top` |
| `microsoft-entra-id_list_user_app_role_assignments` | List the application role assignments held by a user, which is how app access is granted in Entra ID. | **required** `user_id`<br />optional `count`, `filter_query`, `order_by`, `select`, `skip_token`, `top` |
| `microsoft-entra-id_list_user_registration_details` | List which authentication methods each user has registered, for multifactor and passwordless coverage reporting. | optional `filter_query` |
| `microsoft-entra-id_list_users` | List directory users. The starts-with parameters match a prefix; search matches anywhere in a name or mail. When has_more is true, pass next_skip_token back as skip_token. | optional `account_enabled`, `count`, `display_name_starts_with`, `filter_query`, `mail_starts_with`, `order_by`, `search`, `select`, `skip_token`, `top`, `user_principal_name_starts_with` |

## Microsoft Entra ID Governance

23 tools. Available as 2 connections: Microsoft Entra ID Governance (OAuth 2.0), Microsoft Entra ID Governance (GCC High) (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `entra-id-governance_activate_lifecycle_workflow` | Run a lifecycle workflow on-demand for specific users. Use this to trigger onboarding, role change, or offboarding processes immediately. | **required** `workflow_id`, `user_ids` |
| `entra-id-governance_apply_access_review_decisions` | Apply the decisions of a completed access review instance. This enforces the approve/deny decisions by adding or removing access. | **required** `definition_id`, `instance_id` |
| `entra-id-governance_create_access_package_assignment_request` | Create an access package assignment request to grant or revoke a user's access to a package. Supports self-service requests and admin-driven assignments. | **required** `request_type`<br />optional `access_package_id`, `assignment_id`, `assignment_policy_id`, `justification`, `target_user_id` |
| `entra-id-governance_create_group_assignment_request` | Create a group assignment request to directly assign, activate (JIT), or deactivate privileged group membership or ownership. | **required** `action`, `principal_id`, `group_id`, `access_id`<br />optional `expiration_date_time`, `expiration_duration`, `expiration_type`, `justification`, `start_date_time` |
| `entra-id-governance_create_group_eligibility_request` | Create a group eligibility request to make a user eligible for privileged group membership or ownership (or remove/extend/renew eligibility). | **required** `action`, `principal_id`, `group_id`, `access_id`<br />optional `expiration_date_time`, `expiration_duration`, `expiration_type`, `justification`, `start_date_time` |
| `entra-id-governance_create_role_assignment_request` | Create a role assignment request to directly assign, activate (JIT), or deactivate a privileged Entra role. Use selfActivate to activate an eligible role with justification. | **required** `action`, `principal_id`, `role_definition_id`<br />optional `expiration_date_time`, `expiration_duration`, `expiration_type`, `justification`, `start_date_time` |
| `entra-id-governance_create_role_eligibility_request` | Create a role eligibility request to make a user eligible for a privileged Entra role (or remove/extend/renew eligibility). Eligible users can then activate the role via JIT when needed. | **required** `action`, `principal_id`, `role_definition_id`<br />optional `expiration_date_time`, `expiration_duration`, `expiration_type`, `justification`, `start_date_time` |
| `entra-id-governance_get_access_package` | Get details of a specific access package by ID, including its description and catalog. | **required** `access_package_id` |
| `entra-id-governance_get_access_review_definition` | Get details of a specific access review definition, including its scope, reviewers, and recurrence settings. | **required** `definition_id` |
| `entra-id-governance_get_lifecycle_workflow` | Get details of a specific lifecycle workflow including its tasks, execution conditions, and scope. | **required** `workflow_id` |
| `entra-id-governance_list_access_package_assignments` | List current access package assignments. Shows which users have been granted access to which packages and the assignment state. | optional `access_package_id`, `filter_query`, `skip`, `top` |
| `entra-id-governance_list_access_package_catalogs` | List access package catalogs. Catalogs are containers that group related access packages. | optional `filter_query`, `skip`, `top` |
| `entra-id-governance_list_access_packages` | List access packages with optional filtering by catalog. Access packages bundle resources (groups, apps, sites) that users can request access to. | optional `catalog_id`, `filter_query`, `skip`, `top` |
| `entra-id-governance_list_access_review_decisions` | List decisions for a specific access review instance. Shows who was reviewed and what decision was made (Approve, Deny, NotReviewed). | **required** `definition_id`, `instance_id`<br />optional `filter_query`, `skip`, `top` |
| `entra-id-governance_list_access_review_definitions` | List access review schedule definitions. Access reviews periodically verify that users still need access to resources. | optional `filter_query`, `skip`, `top` |
| `entra-id-governance_list_access_review_instances` | List review instances for a given access review definition. Each instance represents a specific review period. | **required** `definition_id`<br />optional `filter_query`, `skip`, `top` |
| `entra-id-governance_list_group_assignment_schedules` | List who has active privileged group membership or ownership. Shows both permanent and time-bound active group assignments. | optional `access_id`, `group_id`, `principal_id`, `skip`, `top` |
| `entra-id-governance_list_group_eligibility_schedules` | List who is eligible for privileged group membership or ownership. Shows JIT-eligible group assignments that users can activate when needed. | optional `access_id`, `group_id`, `principal_id`, `skip`, `top` |
| `entra-id-governance_list_lifecycle_workflow_runs` | List execution history for a lifecycle workflow. Shows when the workflow ran, how many users were processed, and the outcome. | **required** `workflow_id`<br />optional `filter_query`, `skip`, `top` |
| `entra-id-governance_list_lifecycle_workflows` | List lifecycle workflows for automating identity processes. Workflows can be categorized as joiner (onboarding), mover (role change), or leaver (offboarding). | optional `category`, `filter_query`, `skip`, `top` |
| `entra-id-governance_list_role_assignment_schedules` | List who currently has active privileged Entra role assignments. Shows both permanent and time-bound active assignments. | optional `principal_id`, `role_definition_id`, `skip`, `top` |
| `entra-id-governance_list_role_definitions` | List available Entra directory role definitions (e.g., Global Administrator, User Administrator). Use this to find role definition IDs needed for PIM operations. This endpoint does not support pagination -- it always returns the full list. | optional `filter_query` |
| `entra-id-governance_list_role_eligibility_schedules` | List who is currently eligible for which privileged Entra roles. Shows JIT-eligible assignments that users can activate when needed. | optional `principal_id`, `role_definition_id`, `skip`, `top` |

## Microsoft Intune

14 tools. Available as 4 connections: Microsoft Intune (OAuth 2.0), Microsoft Intune (Application) (OAuth 2.0 client credentials), Microsoft Intune (GCC High) (OAuth 2.0), Microsoft Intune (GCC High, Application) (OAuth 2.0 client credentials).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-intune_get_compliance_policy` | Get a single device compliance policy by ID, including its configured settings and rules | **required** `policy_id` |
| `microsoft-intune_get_device_configuration` | Get a single device configuration profile by ID, including its platform-specific settings | **required** `configuration_id` |
| `microsoft-intune_get_managed_device` | Get a single Intune managed device by ID, including hardware details, OS info, compliance state, and enrollment information | **required** `device_id` |
| `microsoft-intune_get_mobile_app` | Get a single managed mobile app by ID, including detailed metadata such as publisher, version, and install status summary | **required** `app_id` |
| `microsoft-intune_list_compliance_policies` | List Intune device compliance policies that define rules devices must meet to be considered compliant. Returns {value: [...], '@odata.nextLink': ...} when more pages are available. | optional `skip`, `top` |
| `microsoft-intune_list_compliance_policy_device_statuses` | List per-device compliance status for a specific policy, showing which devices are compliant, noncompliant, or in error. Returns {value: [...], '@odata.nextLink': ...} when more pages are available. | **required** `policy_id`<br />optional `skip`, `top` |
| `microsoft-intune_list_device_configuration_device_statuses` | List per-device status for a device configuration profile, showing which devices have successfully applied the configuration. Returns {value: [...], '@odata.nextLink': ...} when more pages are available. | **required** `configuration_id`<br />optional `skip`, `top` |
| `microsoft-intune_list_device_configurations` | List Intune device configuration profiles that define settings and restrictions applied to managed devices. Returns {value: [...], '@odata.nextLink': ...} when more pages are available. | optional `skip`, `top` |
| `microsoft-intune_list_managed_devices` | List Intune managed devices with filtering by device name, OS, compliance state, management agent, and user principal name. Returns {value: [...], '@odata.nextLink': ...} when more pages are available. | optional `compliance_state`, `device_name`, `management_agent`, `operating_system`, `skip`, `top`, `user_principal_name` |
| `microsoft-intune_list_mobile_app_device_statuses` | List per-device install status for a specific mobile app, showing which devices have the app installed, pending, or failed. Uses the beta Graph API endpoint. Returns {value: [...]}. | **required** `app_id`<br />optional `skip`, `top` |
| `microsoft-intune_list_mobile_apps` | List Intune managed mobile apps with filtering by display name and app type (e.g., iOS store app, Windows app). Returns {value: [...], '@odata.nextLink': ...} when more pages are available. | optional `app_type`, `display_name`, `skip`, `top` |
| `microsoft-intune_retire_managed_device` | Retire a managed device, removing company data and management profiles while keeping personal data intact | **required** `device_id` |
| `microsoft-intune_sync_managed_device` | Trigger a sync on a managed device, forcing it to check in with Intune for the latest policies and configurations | **required** `device_id` |
| `microsoft-intune_wipe_managed_device` | Wipe (factory reset) a managed device, removing all data. Optionally keep enrollment data or user data. | **required** `device_id`<br />optional `keep_enrollment_data`, `keep_user_data` |

## Okta

44 tools. Credentials are supplied in the connection settings.

| Tool | Description | Arguments |
| --- | --- | --- |
| `okta-private-key_activate_application` | Activate an Okta application | **required** `app_id` |
| `okta-private-key_activate_policy` | Activate an Okta policy | **required** `policy_id` |
| `okta-private-key_activate_policy_rule` | Activate a specific Okta policy rule | **required** `policy_id`, `rule_id` |
| `okta-private-key_activate_user` | Activate or reactivate an Okta user. Reactivates deprovisioned (deactivated) users via the same endpoint. By default (send_email=false) Okta returns an activation URL instead of emailing the user. | **required** `user_id`<br />optional `send_email` |
| `okta-private-key_add_user_to_group` | Add an Okta user to a specific Okta group | **required** `group_id`, `user_id` |
| `okta-private-key_assign_user_to_application` | Assign an Okta user to an application, optionally with app-specific credentials and profile | **required** `app_id`, `user_id`<br />optional `credentials`, `profile` |
| `okta-private-key_create_application` | Create a new Okta application | **required** `app_config`<br />optional `activate` |
| `okta-private-key_create_group` | Create a new Okta group | **required** `profile` |
| `okta-private-key_create_policy` | Create a new Okta policy | **required** `policy_data` |
| `okta-private-key_create_policy_rule` | Create a new rule under a specific Okta policy | **required** `policy_id`, `rule_data` |
| `okta-private-key_create_user` | Create a new Okta user | **required** `profile` |
| `okta-private-key_deactivate_application` | Deactivate an Okta application | **required** `app_id` |
| `okta-private-key_deactivate_policy` | Deactivate an Okta policy | **required** `policy_id` |
| `okta-private-key_deactivate_policy_rule` | Deactivate a specific Okta policy rule | **required** `policy_id`, `rule_id` |
| `okta-private-key_deactivate_user` | Deactivate an Okta user so it can no longer access applications | **required** `user_id` |
| `okta-private-key_delete_application` | Permanently delete an Okta application. This is destructive and cannot be undone. | **required** `app_id` |
| `okta-private-key_delete_deactivated_user` | Permanently delete a previously deactivated Okta user | **required** `user_id` |
| `okta-private-key_delete_group` | Permanently delete an Okta group. This is destructive and cannot be undone. | **required** `group_id` |
| `okta-private-key_delete_policy` | Delete an Okta policy. This is destructive and cannot be undone. | **required** `policy_id` |
| `okta-private-key_delete_policy_rule` | Delete an Okta policy rule. This is destructive and cannot be undone. | **required** `policy_id`, `rule_id` |
| `okta-private-key_expire_password` | Expire an Okta user's password, forcing a change at next sign-in | **required** `user_id` |
| `okta-private-key_get_application` | Retrieve a specific Okta application by ID | **required** `app_id`<br />optional `expand` |
| `okta-private-key_get_group` | Retrieve a specific Okta group by ID | **required** `group_id` |
| `okta-private-key_get_logs` | Retrieve Okta system logs with optional filtering and pagination support | optional `after`, `fetch_all`, `filter_query`, `limit`, `q`, `since`, `until` |
| `okta-private-key_get_policy` | Retrieve a specific Okta policy by ID | **required** `policy_id` |
| `okta-private-key_get_policy_rule` | Retrieve a specific Okta policy rule by ID | **required** `policy_id`, `rule_id` |
| `okta-private-key_get_user` | Retrieve a specific Okta user by ID | **required** `user_id` |
| `okta-private-key_get_user_profile_attributes` | Return the profile attribute names found on a sample user in this Okta org. Returns an empty list if the org has no users. | — |
| `okta-private-key_list_applications` | List Okta applications with optional filtering and pagination support | optional `after`, `expand`, `filter_query`, `include_non_deleted`, `limit`, `q` |
| `okta-private-key_list_group_apps` | List applications assigned to a specific Okta group | **required** `group_id` |
| `okta-private-key_list_group_users` | List users assigned to a specific Okta group | **required** `group_id`<br />optional `after`, `fetch_all`, `limit` |
| `okta-private-key_list_groups` | List Okta groups with optional search, filter, and pagination support | optional `after`, `fetch_all`, `filter_query`, `limit`, `q`, `search` |
| `okta-private-key_list_policies` | List Okta policies for a specific policy type | **required** `policy_type`<br />optional `after`, `limit`, `q`, `status` |
| `okta-private-key_list_policy_rules` | List rules for a specific Okta policy | **required** `policy_id` |
| `okta-private-key_list_users` | List Okta users with optional search, filter, and pagination support | optional `after`, `fetch_all`, `filter_query`, `limit`, `q`, `search` |
| `okta-private-key_remove_user_from_group` | Remove an Okta user from a specific Okta group | **required** `group_id`, `user_id` |
| `okta-private-key_reset_password` | Generate a password reset for an Okta user. By default (send_email=true) Okta emails the reset link and returns no link; set send_email=false to return a resetPasswordUrl instead. | **required** `user_id`<br />optional `send_email` |
| `okta-private-key_suspend_user` | Suspend an active Okta user, blocking sign-in while preserving the account | **required** `user_id` |
| `okta-private-key_unsuspend_user` | Unsuspend a suspended Okta user, returning the account to active status | **required** `user_id` |
| `okta-private-key_update_application` | Update an existing Okta application | **required** `app_id`, `app_config` |
| `okta-private-key_update_group` | Update an existing Okta group | **required** `group_id`, `profile` |
| `okta-private-key_update_policy` | Update an existing Okta policy | **required** `policy_id`, `policy_data` |
| `okta-private-key_update_policy_rule` | Update an existing Okta policy rule | **required** `policy_id`, `rule_id`, `rule_data` |
| `okta-private-key_update_user` | Partially update an Okta user profile using Okta's POST semantics | **required** `user_id`, `profile` |

## SailPoint

59 tools. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `sailpoint_activate_certification_campaign` | Activate a SailPoint certification campaign to start the review process. The campaign deadline must be in the future. Once activated, reviewers receive their certification tasks. Requires CERT_ADMIN or ORG_ADMIN role. | **required** `id`<br />optional `time_zone` |
| `sailpoint_approve_access_request` | Approve a pending access request approval. Only the owner of the approval and ORG_ADMIN users can perform this action. | **required** `approvalId`<br />optional `comment` |
| `sailpoint_cancel_access_request` | Cancel a pending access request. Can only cancel requests that have not passed the approval step. Users with ORG_ADMIN role or the original requestor can cancel. | **required** `accountActivityId`, `comment` |
| `sailpoint_check_sod_violations` | Check SOD violations for an identity and access references. This API initiates a SOD policy verification asynchronously and returns a request ID that can be used to check the status. | **required** `identityId`, `accessRefs` |
| `sailpoint_create_access_profile` | Create a new SailPoint access profile. Access profiles group entitlements from a single source. SOURCE_SUBADMIN or ORG_ADMIN must be associated with the source. | **required** `name`, `owner`, `source`<br />optional `accessRequestConfig`, `description`, `enabled`, `entitlements`, `provisioningCriteria`, `requestable`, `revokeRequestConfig`, `segments` |
| `sailpoint_create_access_request` | Submit an access request to grant or revoke access in SailPoint. Supports roles, access profiles, and entitlements. Requests are processed asynchronously. | **required** `requestedFor`, `requestedItems`<br />optional `clientMetadata`, `requestType` |
| `sailpoint_create_certification_campaign` | Create a new SailPoint certification campaign. Requires CERT_ADMIN or ORG_ADMIN role. | **required** `name`, `type`<br />optional `autoRevokeAllowed`, `correlatedStatus`, `deadline`, `description`, `emailNotificationEnabled`, `filter`, `machineAccountCampaignInfo`, `mandatoryCommentRequirement`, `recommendationsEnabled`, `roleCompositionCampaignInfo`, `searchCampaignInfo`, `sourceOwnerCampaignInfo`, `sunsetCommentsRequired` |
| `sailpoint_create_role` | Create a new SailPoint role. Roles bundle access profiles and entitlements for assignment to identities. ROLE_SUBADMIN users can only create roles with access profiles from sources they administer. | **required** `name`, `owner`<br />optional `accessProfiles`, `accessRequestConfig`, `description`, `enabled`, `entitlements`, `membership`, `requestable`, `revokeRequestConfig`, `segments` |
| `sailpoint_create_sod_policy` | Create a new SailPoint SOD (Segregation of Duties) policy. Requires ORG_ADMIN role. Defines conflicting access criteria that should not be held by the same identity. | **required** `name`, `conflictingAccessCriteria`<br />optional `compensatingControls`, `correctionAdvice`, `description`, `externalPolicyReference`, `ownerRef`, `scheduled`, `state`, `tags`, `violationOwnerAssignmentConfig` |
| `sailpoint_create_source` | Create a new SailPoint source/application. Requires idn:source:manage scope and SOURCE_ADMIN or ORG_ADMIN rights. The source defines a connection to an external system for identity data. | **required** `name`, `owner`, `connector`<br />optional `authoritative`, `cluster`, `connectorAttributes`, `connectorClass`, `deleteThreshold`, `description`, `features`, `provision_as_csv`, `schemas`, `type` |
| `sailpoint_create_workflow` | Create a new SailPoint workflow for automation and process management. | **required** `name`, `owner`<br />optional `definition`, `description`, `enabled`, `trigger` |
| `sailpoint_delete_access_profile` | Delete a SailPoint access profile. Must not be in use by applications, lifecycle states, or roles. | **required** `id` |
| `sailpoint_delete_role` | Delete a SailPoint role by ID. | **required** `id` |
| `sailpoint_delete_sod_policy` | Delete a SailPoint SOD policy. Requires ORG_ADMIN role. Supports soft delete (logical=true, recoverable) and hard delete (logical=false, permanent). | **required** `id`<br />optional `logical` |
| `sailpoint_delete_source` | Delete a SailPoint source/application. Requires idn:source:manage scope and SOURCE_ADMIN or ORG_ADMIN rights. | **required** `id` |
| `sailpoint_delete_workflow` | Delete a SailPoint workflow by ID. | **required** `id` |
| `sailpoint_disable_account` | Disable a SailPoint account. Submits an asynchronous task to disable the account and returns the task ID for tracking. | **required** `id`<br />optional `externalVerificationId`, `forceProvisioning` |
| `sailpoint_enable_account` | Enable a SailPoint account. Submits an asynchronous task to enable the account and returns the task ID for tracking. | **required** `id`<br />optional `externalVerificationId`, `forceProvisioning` |
| `sailpoint_forward_access_request` | Forward an access request approval to a new owner. Only the owner of the approval and ORG_ADMIN users can perform this action. | **required** `approvalId`, `newOwnerId`, `comment` |
| `sailpoint_get_access_profile` | Get a SailPoint access profile by its ID. Returns detailed information about a specific access profile. | **required** `id` |
| `sailpoint_get_account` | Get a single SailPoint account by ID using v2025 API. Returns detailed information about a specific account. | **required** `id` |
| `sailpoint_get_certification_campaign` | Get a single SailPoint certification campaign by ID. Returns full campaign details including status, deadline, and configuration. | **required** `id` |
| `sailpoint_get_identity` | Get a single identity by ID using v2025 API. Returns detailed information about a specific identity. | **required** `id` |
| `sailpoint_get_identity_profile` | Get a single identity profile by ID. This API returns a single identity profile by its ID. | **required** `id` |
| `sailpoint_get_isc_run_context` | Read-only ISC run-context diagnostics. Returns recent task results so an operator can see current run state before taking action. No mutations. Reads the experimental v2025 task-status endpoint. | optional `filters`, `limit` |
| `sailpoint_get_job_status` | Poll an account aggregation job by ID and return its status and progress (NEW/CHANGED/DELETED account counts). Read-only. | **required** `id` |
| `sailpoint_get_role` | Get a role by ID. A user with ROLE_SUBADMIN authority may only call this API if all access profiles included in the role are associated to sources with management workgroups of the ROLE_SUBADMIN is a member of. | **required** `id` |
| `sailpoint_get_sod_policy` | Get a specified SOD (Segregation of Duties) policy by its ID. Requires role of ORG_ADMIN. | **required** `id` |
| `sailpoint_get_source` | Get a single source by ID using v2025 API. Returns detailed information about a specific source including SSO/MFA configuration. | **required** `id` |
| `sailpoint_get_task_status` | Poll a SailPoint task by ID and return its status (completed, failed, or running). Read-only. Covers account/entitlement aggregation and other background tasks. The upstream v2025 task-status endpoint is experimental. | **required** `id` |
| `sailpoint_get_workflow` | Get a single workflow by ID using v2025 API. Returns detailed information about a specific workflow including its definition and configuration. | **required** `id` |
| `sailpoint_list_access_profile_entitlements` | Get a list of an access profile's entitlements. A SOURCE_SUBADMIN user must have access to the source associated with the specified access profile. | **required** `id`<br />optional `count`, `filters`, `limit`, `offset`, `sorters` |
| `sailpoint_list_access_profiles` | Get a list of SailPoint access profiles. Note: When you filter for access profiles that have the "+" symbol in their names, the response is blank. | optional `count`, `filters`, `for_segment_ids`, `for_subadmin`, `include_unsegmented`, `limit`, `offset`, `sorters` |
| `sailpoint_list_access_request_status` | Get SailPoint access request statuses with optional filtering and pagination using v2025 API. Any user can get the status of their own access requests. ORG_ADMIN is required to get statuses for other users. | optional `assigned-to`, `count`, `filters`, `limit`, `offset`, `regarding-identity`, `request-state`, `requested-by`, `requested-for`, `sorters` |
| `sailpoint_list_account_entitlements` | Get entitlements for a specific account using v3 API. Returns all entitlements associated with the specified account. | **required** `accountId`<br />optional `count`, `filters`, `limit`, `offset`, `sorters` |
| `sailpoint_list_accounts` | Get a list of SailPoint accounts with optional filtering, sorting, and pagination support using v2025 API. IMPORTANT: To get ALL account data, make multiple tool calls with the required offset values to paginate through all results. | optional `count`, `filters`, `limit`, `offset`, `sorters` |
| `sailpoint_list_certification_campaigns` | Get a list of SailPoint certification campaigns with optional filtering, sorting, and pagination. | optional `count`, `filters`, `limit`, `offset`, `sorters` |
| `sailpoint_list_completed_approvals` | Get a list of completed access request approvals with optional filtering, sorting, and pagination. ORG_ADMIN users can view all completed approvals. Non-ORG_ADMIN users can only view their own. | optional `count`, `filters`, `limit`, `offset`, `owner-id`, `sorters` |
| `sailpoint_list_identities` | Get a list of identities with optional filtering, sorting, and pagination support using v2025 API. By default, returns only correlated identities (defaultFilter=CORRELATED_ONLY). | optional `count`, `defaultFilter`, `filters`, `limit`, `offset`, `sorters` |
| `sailpoint_list_identity_profiles` | Get a list of identity profiles. This API returns a list of identity profiles based on the specified query parameters with optional filtering, sorting, and pagination. | optional `count`, `filters`, `limit`, `offset`, `sorters` |
| `sailpoint_list_pending_approvals` | Get a list of pending access request approvals with optional filtering, sorting, and pagination. ORG_ADMIN users can view all pending approvals. Non-ORG_ADMIN users can only view their own. | optional `count`, `filters`, `limit`, `offset`, `owner-id`, `sorters` |
| `sailpoint_list_role_assigned_identities` | List identities assigned a role. This API lists all identities assigned to a specific role with optional filtering, sorting, and pagination. | **required** `id`<br />optional `count`, `filters`, `limit`, `offset`, `sorters` |
| `sailpoint_list_roles` | Get a list of Roles. This API returns a list of Roles with optional filtering, sorting, and pagination support. IMPORTANT: To get ALL role data, make multiple tool calls with different offset values to paginate through all results. | optional `count`, `filters`, `for_segment_ids`, `for_subadmin`, `include_unsegmented`, `limit`, `offset`, `sorters` |
| `sailpoint_list_sod_policies` | Get a list of all SOD (Segregation of Duties) policies. Requires role of ORG_ADMIN. | optional `count`, `filters`, `limit`, `offset`, `sorters` |
| `sailpoint_list_sources` | Get a list of sources/applications for inventory and configuration management using v2025 API. IMPORTANT: To get ALL source data, make multiple tool calls with different offset values to paginate through all results. | optional `count`, `filters`, `limit`, `offset`, `sorters` |
| `sailpoint_list_task_results` | List completed/historical SailPoint task results with optional filtering, sorting, and pagination. Read-only. The upstream v2025 task-status endpoint is experimental. | optional `count`, `filters`, `limit`, `offset`, `sorters` |
| `sailpoint_list_workflows` | Get a list of workflows for automation and process management using v2025 API. | optional `count`, `filters`, `limit`, `offset`, `sorters` |
| `sailpoint_patch_access_profile` | Update an existing SailPoint access profile using JSON Patch (RFC 6902). Patchable fields: name, description, enabled, owner, requestable, accessRequestConfig, revokeRequestConfig, segments, entitlements, provisioningCriteria, source. | **required** `id`, `operations` |
| `sailpoint_patch_role` | Update an existing SailPoint role using JSON Patch (RFC 6902). | **required** `id`, `operations` |
| `sailpoint_patch_sod_policy` | Update an existing SailPoint SOD policy using JSON Patch (RFC 6902). Requires ORG_ADMIN role. | **required** `id`, `operations` |
| `sailpoint_patch_source` | Update an existing SailPoint source using JSON Patch (RFC 6902). Requires idn:source:manage scope and SOURCE_ADMIN or ORG_ADMIN rights. | **required** `id`, `operations` |
| `sailpoint_patch_workflow` | Update an existing SailPoint workflow using JSON Patch (RFC 6902). Patchable fields: name, owner, description, enabled, definition, trigger. | **required** `id`, `operations` |
| `sailpoint_reject_access_request` | Reject a pending access request approval. Only the owner of the approval and ORG_ADMIN users can perform this action. | **required** `approvalId`<br />optional `comment` |
| `sailpoint_reprocess_identity_jml` | Reprocess identity JML lifecycle state (recalculate attributes, role assignments, provisioning, manager relationships) for one or more identities. Guardrail: single identity or a capped batch only; unbounded batches are rejected. | **required** `identity_ids` |
| `sailpoint_rerun_source_aggregation` | Re-run a source account aggregation. Guardrails: source_id must be in allowed_source_ids (allowlist), DELTA aggregation by default, and FULL (unoptimized) aggregation requires approve_full_aggregation=true. | **required** `source_id`, `allowed_source_ids`<br />optional `aggregation_type`, `approve_full_aggregation` |
| `sailpoint_retry_failed_job` | Retry a failed source aggregation job. | **required** `source_id`, `allowed_source_ids`, `failure_status`, `attempt` |
| `sailpoint_search` | Search across SailPoint objects using Elasticsearch syntax. Supports searching identities, roles, access profiles, entitlements, events, and account activities. Powerful tool for querying across all SailPoint data. | **required** `indices`<br />optional `count`, `includeNested`, `limit`, `offset`, `query`, `queryDsl`, `searchAfter`, `sort` |
| `sailpoint_test_workflow` | Test a SailPoint workflow by executing it with mock trigger input. Useful for validating workflow logic before enabling. | **required** `id`, `input` |
| `sailpoint_unlock_account` | Unlock a SailPoint account. Submits an asynchronous task to unlock the account and returns the task ID for tracking. Requires idn:accounts-provisioning:manage scope for forceProvisioning. | **required** `id`<br />optional `externalVerificationId`, `forceProvisioning` |

## Saviynt Enterprise Identity Cloud

24 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `saviynt_bulk_upload_users` | Bulk create/update users from a CSV in Saviynt (uploadUserRequest). Sent as multipart/form-data with the CSV file plus option flags. | **required** `csv_content`<br />optional `checkrules`, `delimiter`, `generate_email`, `generate_system_username`, `zero_day_provisioning` |
| `saviynt_complete_provisioning_task` | Complete one or more Saviynt provisioning tasks and verify the outcome. A single task with no extra fields completes via completetask; multiple tasks, or a comment/ticket/metadata, complete via updateTasks (updatetype=completetask). | **required** `task_ids`<br />optional `comments`, `provisioning_metadata`, `ticket_id`, `verify` |
| `saviynt_create_user` | Create a user in Saviynt (createUser). Core attributes are named params; pass arbitrary extra attributes via `attributes`. | **required** `username`<br />optional `attributes`, `email`, `firstname`, `lastname`, `statuskey`, `systemusername`, `validateagainstpolicy` |
| `saviynt_decide_access_request` | Act on a pending Saviynt access request: approve, reject, or cancel (discontinue) it. Approve and reject both need both identifiers of the pending request: its requestkey and its requestid, as returned by list_access_requests. | **required** `request_key`, `action`<br />optional `reason`, `request_id` |
| `saviynt_discontinue_provisioning_task` | Discontinue one or more Saviynt provisioning tasks that are still new or pending, recording comments on each task's history, then verify their status. Irreversible: a discontinued task cannot be completed later. | **required** `task_ids`, `comments`<br />optional `discontinue_associated`, `verify` |
| `saviynt_fetch_job_metadata` | Fetch metadata and run history for a Saviynt job (fetchJobMetadata). Read-only; complements get_job_status for completion detail. | **required** `jobname`<br />optional `jobgroup`, `jobstartdate`, `triggername` |
| `saviynt_get_access_request` | Get one access request's detail with optional approval and user-access sections. | **required** `request_id`<br />optional `include`, `response_format`, `username` |
| `saviynt_get_job_status` | Get the current status of a Saviynt job trigger (checkJobStatus). Read-only; use to poll a trigger fired via the run_* tools. Returns errorCode/msg. | **required** `jobname`, `jobgroup`<br />optional `triggername` |
| `saviynt_get_provisioning_task_status` | Get the status of a single Saviynt provisioning task by id (checkTaskStatus). Read-only. | **required** `taskid` |
| `saviynt_get_tasks` | List provisioning tasks in Saviynt via fetchTasks. status is required (the API has no ERROR value, so errored tasks are not queryable here). | **required** `status`<br />optional `endpoint`, `max_results`, `offset`, `task_type`, `username` |
| `saviynt_get_user_access` | Fetch one user's profile, access, and in-flight work as one view. | **required** `username`<br />optional `endpoint`, `include`, `max_per_section`, `response_format` |
| `saviynt_list_access_requests` | List Saviynt access-request history as summary rows (fetchRequestHistory): one row per request with its requestkey, requestid, requestor, status, and dates. | optional `max_results`, `offset`, `order`, `request_id`, `requested_for`, `sort`, `status`, `username` |
| `saviynt_list_certification_campaigns` | List certification campaigns in Saviynt (campaigns pending certification). Optionally scope to a certifier username; supports max/offset pagination. | optional `max_results`, `offset`, `username` |
| `saviynt_list_users` | List or search users in Saviynt Enterprise Identity Cloud. Filter by username and limit the returned attributes; supports max/offset pagination. Use manager to list one manager's direct reports in a single call. | optional `manager`, `max_results`, `offset`, `user_response_fields`, `username` |
| `saviynt_process_identity_rules` | Fire a Saviynt identity-rules processing job trigger (runJobTrigger). Async: the trigger is queued, not awaited — poll get_job_status / fetch_job_metadata for completion. | **required** `jobname`, `jobgroup`, `triggername`<br />optional `create_job_if_does_not_exist`, `value_map` |
| `saviynt_query_entitlements` | Query entitlements in Saviynt Enterprise Identity Cloud. Filter by entitlement type and endpoint (application), restrict returned fields, and paginate with max/offset. | optional `endpoint`, `entitlement_response_fields`, `entitlement_type`, `max_results`, `offset` |
| `saviynt_run_identity_refresh` | Fire a Saviynt identity-refresh job trigger (runJobTrigger). Async: the trigger is queued, not awaited — poll get_job_status / fetch_job_metadata for completion. jobname/jobgroup/triggername are tenant-specific and caller-supplied. | **required** `jobname`, `jobgroup`, `triggername`<br />optional `create_job_if_does_not_exist`, `value_map` |
| `saviynt_run_source_import_or_aggregation` | Fire a Saviynt source-import / aggregation job trigger (runJobTrigger). Async: the trigger is queued, not awaited — poll get_job_status / fetch_job_metadata for completion. | **required** `jobname`, `jobgroup`, `triggername`<br />optional `create_job_if_does_not_exist`, `value_map` |
| `saviynt_run_ws_retry_job` | Fire the Saviynt WSRETRY job trigger to retry failed provisioning tasks (runJobTrigger). Async: poll get_job_status / fetch_job_metadata for completion. | **required** `triggername`<br />optional `create_job_if_does_not_exist`, `jobgroup`, `jobname`, `security_systems`, `task_types` |
| `saviynt_submit_access_request` | Submit an access request in Saviynt (requestAccess) — request one or more entitlements/accounts for a user. The endpoint apiName is version-dependent: a 404 may mean this tenant uses a different apiName. | **required** `username`, `requestor`, `requestaccess`<br />optional `comments` |
| `saviynt_submit_user_update_request` | Submit a governed user-update request in Saviynt (updateUserRequest) — routed through request workflow rather than applied directly. The endpoint apiName is version-dependent: a 404 may mean this tenant uses a different apiName. | **required** `username`, `attributes` |
| `saviynt_update_sav_role_members` | Add users to, or remove users from, a Saviynt SAV role (the platform roles that control what a user can do in Saviynt itself, not application access). | **required** `sav_role`, `usernames`, `action` |
| `saviynt_update_user` | Update an existing Saviynt user (updateUser). `username` identifies the record; changed attributes are supplied via `attributes`. | **required** `username`, `attributes` |
| `saviynt_upsert_user_group` | Create a Saviynt user group or modify an existing one (createUpdateUserGroup handles both). usergroup_name identifies the group. | **required** `usergroup_name`<br />optional `add_members`, `attributes`, `description`, `remove_members` |

---

## Cloud and infrastructure

Source: https://docs.kindo.ai/reference/tool-catalog/cloud-infrastructure/

:::note[Beta]
The tool catalog is in beta and is a point-in-time snapshot of the integration inventory, so an entry can differ from what your organization sees in product.
:::

Cloud providers, orchestration, and observability platforms an agent can inspect and operate. 16 integrations, 255 tools.

Tool names below are the fully qualified names an agent sees once the integration is connected. Where an integration offers more than one connection, the names shown use the primary connection's prefix; connecting through another variant prefixes its tools with that variant's own integration ID instead. See [Tool Catalog](/reference/tool-catalog/) for how tools are granted and named.

## AWS Shield Advanced

6 tools. Credentials are supplied in the connection settings.

| Tool | Description | Arguments |
| --- | --- | --- |
| `aws-shield_describe_attack` | Describe a single DDoS attack by its attack id. Returns full attack detail: vectors, traffic counters, properties (top contributors, geos, sources), and applied mitigations. | **required** `attack_id` |
| `aws-shield_describe_protection` | Describe a single AWS Shield Advanced protection by its protection id OR by the protected resource's ARN — provide exactly one of the two. Returns the protection's full metadata. | optional `protection_id`, `resource_arn` |
| `aws-shield_describe_subscription` | Return the account's AWS Shield Advanced subscription details: start/end time, auto-renew status, proactive engagement status, and subscription limits. Useful for billing reviews or expiration checks. | — |
| `aws-shield_get_subscription_state` | Return the current AWS Shield Advanced subscription state for the account: 'ACTIVE' or 'INACTIVE'. Use this as the fast preflight before any other Shield tool — most Shield APIs require an active subscription. | — |
| `aws-shield_list_attacks` | List DDoS attack summaries observed by AWS Shield Advanced in a time window, optionally filtered by resource ARN. Returns lightweight attack metadata (id, target, vectors, start/end). Use describe_attack for full detail. | optional `end_time`, `max_results`, `next_token`, `resource_arns`, `start_time` |
| `aws-shield_list_protections` | List AWS Shield Advanced protections in the account, optionally filtered by resource ARN, protection name, or AWS resource type. Returns protection metadata (id, name, resource ARN, health check associations). Paginate via next_token. | optional `max_results`, `next_token`, `protection_names`, `resource_arns`, `resource_types` |

## Cisco Catalyst Center

15 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cisco-catalyst_apply_anc_policy` | Apply Adaptive Network Control (ANC) policy to an endpoint | **required** `epId`, `ancPolicy`<br />optional `granularAncPolicy` |
| `cisco-catalyst_create_profiling_rule` | Create a new profiling rule for device classification | **required** `ruleName`, `conditions`, `actions`<br />optional `priority` |
| `cisco-catalyst_get_acl_statistics` | Get performance statistics for a specific ACL | **required** `deviceId`, `aclName`<br />optional `timeRange` |
| `cisco-catalyst_get_anc_policies` | List all available ANC policies | optional `limit`, `offset` |
| `cisco-catalyst_get_client_details` | Get detailed information about a network client device or user (macAddress or userId is required) | optional `macAddress`, `userId` |
| `cisco-catalyst_get_device` | Get detailed information for a specific network device | **required** `deviceId` |
| `cisco-catalyst_get_device_acls` | Get ACLs configured on a specific device | **required** `deviceId`<br />optional `interfaceType` |
| `cisco-catalyst_get_endpoint_details` | Get detailed information about a specific endpoint | **required** `epId` |
| `cisco-catalyst_get_issue_details` | Get detailed context and recommended actions for a network issue or alert (issueId or clientMac is required) | optional `clientMac`, `issueId` |
| `cisco-catalyst_list_devices` | List all network devices from Catalyst Center with optional filtering | optional `managementIp`, `serialNumber` |
| `cisco-catalyst_list_profiling_rules` | List profiling rules with optional filters | optional `limit`, `offset`, `ruleType` |
| `cisco-catalyst_list_sites` | List site hierarchy or filter by site name from Catalyst Center | optional `name` |
| `cisco-catalyst_query_endpoints` | Query endpoints with optional filters | optional `ipAddress`, `limit`, `macAddress`, `offset`, `profiling` |
| `cisco-catalyst_register_endpoint` | Register a new endpoint in the system | **required** `macAddress`<br />optional `profileId`, `staticGroupAssignment` |
| `cisco-catalyst_revoke_anc_policy` | Revoke ANC policy from an endpoint | **required** `epId` |

## Cisco Firepower Management Center

23 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cisco-fmc_create_access_rule` | Create a new access-control rule inside an AC policy. By default the rule is appended to the bottom of the rule list; set ``insert_before`` or ``insert_after`` to position it. | **required** `policy_id`, `name`, `action`<br />optional `destination_networks`, `destination_zones`, `domain_uuid`, `enabled`, `insert_after`, `insert_before`, `log_begin`, `log_end`, `send_events_to_fmc`, `source_networks`, `source_zones` |
| `cisco-fmc_create_network_object` | Create a new network-layer object. | **required** `name`, `value`, `kind`<br />optional `description`, `domain_uuid` |
| `cisco-fmc_delete_access_rule` | Delete an access-control rule by ID. Does NOT deploy — call ``deploy_to_devices`` separately to push the removal to firewalls. | **required** `policy_id`, `rule_id`<br />optional `domain_uuid` |
| `cisco-fmc_deploy_to_devices` | Push pending configuration changes to one or more devices. Returns a task descriptor immediately (deployment is async) — poll ``get_task_status`` with the returned ``id`` until ``state`` is ``Success`` or ``Failed``. | **required** `device_ids`<br />optional `deployment_note`, `domain_uuid`, `force_deploy`, `ignore_warning` |
| `cisco-fmc_get_access_policy` | Get a single AC policy by UUID (default action, inheritance, etc.). | **required** `policy_id`<br />optional `domain_uuid` |
| `cisco-fmc_get_device` | Get full detail for a single managed device (interfaces, HA peer, health, deployment status, etc.) by its FMC UUID. | **required** `device_id`<br />optional `domain_uuid` |
| `cisco-fmc_get_intrusion_policy` | Get a single intrusion policy by UUID (base policy, rule overrides, etc.). | **required** `policy_id`<br />optional `domain_uuid` |
| `cisco-fmc_get_network_object` | Get a single network object by ID. ``kind`` selects the underlying type-specific endpoint (Host / Network / Range / FQDN). | **required** `object_id`, `kind`<br />optional `domain_uuid` |
| `cisco-fmc_get_server_info` | Get the FMC server's version metadata: ``serverVersion``, ``geoVersion``, ``vdbVersion``, ``sruVersion`` (some optional depending on the FMC build). | — |
| `cisco-fmc_get_task_status` | Get the state of an async FMC task (deployment, device push, etc.). State is one of: Pending, Running, Success, Failed, Retry. Returns the full task envelope including any error messages on Failed. | **required** `task_id`<br />optional `domain_uuid` |
| `cisco-fmc_list_access_policies` | List access-control (AC) policies in the given domain. AC policies are the top-level rule containers attached to devices. | optional `domain_uuid`, `limit` |
| `cisco-fmc_list_access_rules` | List access-control rules inside one AC policy. Returns the rules in policy-evaluation order. | **required** `policy_id`<br />optional `domain_uuid`, `filter_expr`, `limit` |
| `cisco-fmc_list_deployable_devices` | List devices with pending (undeployed) configuration changes in the given domain. Each entry includes the device ID and the version that would be deployed. | optional `domain_uuid`, `limit` |
| `cisco-fmc_list_devices` | List managed FTD / Firepower devices in the given FMC domain. Returns ID, name, model, software version, health, and HA / cluster membership for each device. Paginated. | optional `domain_uuid`, `limit` |
| `cisco-fmc_list_domains` | List all FMC domains the current credentials can access. Returns a name → UUID mapping. Domains partition FMC for multi-tenant or segmented (defense) deployments; the result feeds the optional ``domain_uuid`` parameter on every other tool. | — |
| `cisco-fmc_list_intrusion_policies` | List Snort 2 / Snort 3 intrusion-prevention policies in the given domain. Read-only — intrusion-rule CRUD lives in a separate admin workflow. | optional `domain_uuid`, `limit` |
| `cisco-fmc_list_network_groups` | List network groups (named collections of network objects + inline IP/CIDR literals) in the given domain. | optional `domain_uuid`, `limit`, `name_filter` |
| `cisco-fmc_list_network_objects` | List network-layer objects (Hosts, Networks, Ranges, FQDNs) in the given domain. | optional `domain_uuid`, `limit`, `name_filter` |
| `cisco-fmc_list_policy_assignments` | List policy → device assignments in the given domain. Useful before mutating a policy to know which devices will receive the change on the next deployment. | optional `domain_uuid`, `limit` |
| `cisco-fmc_list_security_zones` | List security zones in the given domain. Zone object IDs are needed when crafting access-control rules whose match criteria include source / destination zones. | optional `domain_uuid`, `limit` |
| `cisco-fmc_search_audit_records` | Search the FMC audit trail. ``filter_expr`` accepts FMC audit filter keys joined by ``;``. **Verified live against FMC 7.2.9:** ``username``. | optional `domain_uuid`, `filter_expr`, `limit` |
| `cisco-fmc_update_access_rule` | Update fields on an existing access-control rule. | **required** `policy_id`, `rule_id`<br />optional `action`, `destination_networks`, `domain_uuid`, `enabled`, `name`, `source_networks` |
| `cisco-fmc_update_network_group_members` | Append / remove / replace members of an existing network group. | **required** `group_id`, `op`<br />optional `domain_uuid`, `literals`, `object_ids` |

## Cisco Secure Workload

25 tools. Credentials are supplied in the connection settings.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cisco-secure-workload_count_inventory` | Count workloads matching an inventory filter. Faster than search when only the count is needed. | **required** `filter_query`<br />optional `scope_name` |
| `cisco-secure-workload_create_alert` | Create a new alert with a name, severity level, and trigger filter. Alerts notify when specific conditions are met in the workload environment. | **required** `name`, `severity`, `alert_filter` |
| `cisco-secure-workload_create_application` | Create a new application (workspace) within a scope. Applications are containers for security policies. | **required** `app_scope_id`, `name`<br />optional `description`, `primary` |
| `cisco-secure-workload_create_policy` | Create a new micro-segmentation policy within an application. Defines traffic rules between consumer (source) and provider (destination) inventory filters with ALLOW or DENY action. | **required** `application_id`, `consumer_filter_id`, `provider_filter_id`, `policy_action`<br />optional `priority`, `rank`, `version` |
| `cisco-secure-workload_create_scope` | Create a new scope under a parent scope. Scopes use filter queries to define which workloads belong to them (e.g. by subnet or label). | **required** `short_name`, `parent_app_scope_id`<br />optional `short_query` |
| `cisco-secure-workload_delete_policy` | Delete a policy by its ID. | **required** `policy_id` |
| `cisco-secure-workload_disable_enforcement` | Disable policy enforcement for an application. This deactivates micro-segmentation rules without deleting policies. | **required** `application_id` |
| `cisco-secure-workload_enable_enforcement` | Enable policy enforcement for an application. This activates micro-segmentation rules on workloads in the scope. | **required** `application_id` |
| `cisco-secure-workload_get_alert` | Get details of a specific alert by its ID. | **required** `alert_id` |
| `cisco-secure-workload_get_application` | Get details of a specific application (workspace) by its ID. | **required** `application_id` |
| `cisco-secure-workload_get_application_details` | Get full details of an application including its policies, clusters, and enforcement status. More comprehensive than get_application. | **required** `application_id` |
| `cisco-secure-workload_get_policy` | Get details of a specific policy by its ID. | **required** `policy_id` |
| `cisco-secure-workload_get_scope` | Get details of a specific scope by its ID. | **required** `scope_id` |
| `cisco-secure-workload_get_sensor` | Get details of a specific sensor (software agent) by its ID. | **required** `sensor_id` |
| `cisco-secure-workload_get_top_flows` | Get the top N flows ranked by a metric (packets, bytes) for a given dimension (source IP, destination port, protocol). Useful for identifying top talkers or busiest connections. | **required** `filter_query`, `start_time`, `end_time`, `dimension`<br />optional `metric`, `threshold` |
| `cisco-secure-workload_get_workload` | Get detailed information about a specific workload including hostname, OS, interfaces, labels, and running processes. | **required** `workload_id` |
| `cisco-secure-workload_get_workload_vulnerabilities` | Get known vulnerabilities (CVEs) for a specific workload. Returns vulnerability details based on installed packages. | **required** `workload_id` |
| `cisco-secure-workload_list_alerts` | List all configured alerts in Cisco Secure Workload. | — |
| `cisco-secure-workload_list_applications` | List all applications (workspaces) in Cisco Secure Workload. Applications group policies for a given scope. | — |
| `cisco-secure-workload_list_policies` | List all policies for an application. Policies define allowed or denied traffic between consumer and provider inventory filters. | **required** `application_id`<br />optional `version` |
| `cisco-secure-workload_list_scopes` | List all scopes (organizational groupings) in Cisco Secure Workload. Scopes define the boundaries for policy enforcement and visibility. | — |
| `cisco-secure-workload_list_sensors` | List all sensors (software agents) deployed on workloads. Shows sensor status, version, and host information. | — |
| `cisco-secure-workload_search_change_logs` | Search the audit change logs for API operations performed on the Cisco Secure Workload instance. Useful for tracking who made what changes and when. | **required** `start_time`, `end_time`<br />optional `limit`, `method`, `uri` |
| `cisco-secure-workload_search_flows` | Search network flow records with filters. Returns flow data including source/destination IPs, ports, protocols, byte/packet counts, and policy decisions. | **required** `filter_query`, `start_time`, `end_time`<br />optional `limit`, `offset` |
| `cisco-secure-workload_search_inventory` | Search the workload inventory using filter queries. Returns matching hosts, VMs, and containers with their attributes (IP, hostname, OS, labels, tags). | **required** `filter_query`<br />optional `limit`, `offset`, `scope_name` |

## Cisco Wireless LAN Controller

13 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cisco-wireless-lan-controller_create_wlan` | Create a new WLAN/SSID on the controller. Requires a unique profile name, a WLAN ID (1-4096), and the broadcast SSID. The WLAN is created disabled unless 'enabled' is set to true. | **required** `profile_name`, `wlan_id`, `ssid`<br />optional `enabled` |
| `cisco-wireless-lan-controller_delete_wlan` | Delete a WLAN/SSID from the controller by its profile name. | **required** `profile_name` |
| `cisco-wireless-lan-controller_get_access_point` | Get a single access point's CAPWAP operational data by its radio MAC address (wtp-mac), e.g. 'aaaa.bbbb.cccc' or 'aa:bb:cc:dd:ee:ff'. | **required** `wtp_mac` |
| `cisco-wireless-lan-controller_get_client` | Get a single wireless client's operational data by its MAC address (client-mac list key). | **required** `client_mac` |
| `cisco-wireless-lan-controller_get_controller_summary` | Get controller-wide AP operational summary (AP join statistics, per-band radio counts, predownload status) from ap-global-oper-data. | optional `depth` |
| `cisco-wireless-lan-controller_get_wlan` | Get a single WLAN/SSID configuration by its profile name. | **required** `profile_name` |
| `cisco-wireless-lan-controller_list_access_points` | List access points joined to the Catalyst 9800 controller (CAPWAP operational data: AP name, radio MAC, model, IP, join state). RESTCONF returns the full AP list; use 'fields'/'depth' to trim the payload and 'limit' to cap results. | optional `depth`, `fields`, `limit` |
| `cisco-wireless-lan-controller_list_clients` | List wireless clients currently associated to the controller (common operational data: client MAC, AP name/MAC, WLAN ID, association state). Use 'fields'/'depth' to trim and 'limit' to cap. | optional `depth`, `fields`, `limit` |
| `cisco-wireless-lan-controller_list_rogue_aps` | List rogue access points detected by the controller, including classification, RSSI, and containment state. | optional `depth`, `fields`, `limit` |
| `cisco-wireless-lan-controller_list_rrm_radio_data` | List Radio Resource Management (RRM) / RF operational data per AP radio. Choose a category: 'auto-rf' (channel/tx-power neighbor data), 'radar' (DFS radar events), 'spectrum' (spectrum analysis), or 'radio-slot' (per-slot radio info). | optional `category`, `limit` |
| `cisco-wireless-lan-controller_list_wlans` | List configured WLAN/SSID entries on the controller (profile name, WLAN ID, SSID, admin status, security settings). | optional `depth`, `fields`, `limit` |
| `cisco-wireless-lan-controller_reset_access_point` | Reset (reboot) an access point via the ap-reset RPC. Identify the AP by EITHER its name or its MAC address (provide exactly one). This is a disruptive operation: the AP and its clients drop while it reboots. | optional `ap_name`, `mac_addr` |
| `cisco-wireless-lan-controller_update_wlan` | Update an existing WLAN by profile name. Only the provided fields are changed (PATCH/merge). Use 'enabled' to toggle admin status, 'ssid' to rename the broadcast SSID. | **required** `profile_name`<br />optional `enabled`, `ssid` |

## Cloudflare (API Key)

35 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cloudflare-api_export_all_rules` | Export combined IP access, legacy firewall, custom WAF, lockdown, and UA rules. | optional `account_id`, `output_format`, `zone_id` |
| `cloudflare-api_export_custom_rules` | Export custom WAF rules from the http_request_firewall_custom entrypoint. | optional `output_format`, `zone_id` |
| `cloudflare-api_export_ip_access_rules` | Export all zone and account IP access rules as JSON or CSV. | optional `account_id`, `output_format`, `zone_id` |
| `cloudflare-api_get_account_ip_access_rule` | Get a specific account-level IP access rule (account_id required). | **required** `rule_id`, `account_id` |
| `cloudflare-api_get_account_rulesets` | List account-level rulesets (all accounts or one account_id). | optional `account_id`, `summary_only` |
| `cloudflare-api_get_dns_query_analytics` | DNS query analytics via GraphQL (Pro+ / analytics entitlements often required). Cross-references low-traffic query names with configured DNS records. | optional `days`, `query_threshold`, `zone_id` |
| `cloudflare-api_get_dns_record` | Get a DNS record by ID (zone_id required). | **required** `zone_id`, `record_id` |
| `cloudflare-api_get_dns_statistics` | Aggregate DNS record counts by type and proxied vs DNS-only. | optional `zone_id` |
| `cloudflare-api_get_dnssec_status` | DNSSEC status and configuration for zone(s). | optional `zone_id` |
| `cloudflare-api_get_rule_statistics` | Security posture overview: aggregated rule counts by category per zone. | optional `zone_id` |
| `cloudflare-api_get_ruleset_details` | Fetch one ruleset by ID (tries each zone if zone_id omitted). | **required** `ruleset_id`<br />optional `zone_id` |
| `cloudflare-api_get_security_level` | Get zone security_level setting (off/low/medium/high/under_attack). | optional `zone_id` |
| `cloudflare-api_get_ssl_settings` | Get SSL/TLS mode (off/flexible/full/strict) for zone(s). | optional `zone_id` |
| `cloudflare-api_get_ssl_verification_status` | SSL certificate verification / DCV status for zone(s). | optional `zone_id` |
| `cloudflare-api_get_tls_version` | Get minimum TLS version setting for zone(s). | optional `zone_id` |
| `cloudflare-api_get_ua_rule` | Get a User-Agent rule by ID (searches zones if zone_id omitted). | **required** `rule_id`<br />optional `zone_id` |
| `cloudflare-api_get_waf_package_rules` | List rules inside a legacy WAF package (paginated internally). | **required** `package_id`<br />optional `summary_only`, `zone_id` |
| `cloudflare-api_get_waf_rule_details` | Get a single legacy WAF rule (tries all zones if zone_id omitted). | **required** `package_id`, `rule_id`<br />optional `zone_id` |
| `cloudflare-api_get_zone_ip_access_rule` | Get one zone IP access rule by ID (searches zones if zone_id omitted). | **required** `rule_id`<br />optional `zone_id` |
| `cloudflare-api_get_zone_lockdown` | Get one Zone Lockdown by ID (searches zones if zone_id omitted). | **required** `lockdown_id`<br />optional `zone_id` |
| `cloudflare-api_get_zone_security_settings` | Return all zone settings (includes security-related keys). | optional `summary_only`, `zone_id` |
| `cloudflare-api_list_account_ip_access_rules` | List account-wide IP access rules (paginated per account). | optional `account_id`, `summary_only` |
| `cloudflare-api_list_accounts` | List Cloudflare accounts visible to the API token (paginated internally). | optional `summary_only` |
| `cloudflare-api_list_custom_rules` | List custom WAF rules from the http_request_firewall_custom entrypoint ruleset. | optional `summary_only`, `zone_id` |
| `cloudflare-api_list_dns_records` | List DNS records for zone(s); optional type/name filters. | optional `name`, `record_type`, `summary_only`, `zone_id` |
| `cloudflare-api_list_firewall_rules` | List legacy firewall rules for a zone (deprecated API; read-only). | optional `summary_only`, `zone_id` |
| `cloudflare-api_list_legacy_rate_limits` | List legacy rate limit rules (deprecated /rate_limits) per zone. | optional `summary_only`, `zone_id` |
| `cloudflare-api_list_managed_rulesets` | List rulesets configured on a zone (WAF managed rules entrypoints). | optional `summary_only`, `zone_id` |
| `cloudflare-api_list_rate_limit_rules` | List new ruleset-based rate limit rules (http_ratelimit entrypoint). | optional `summary_only`, `zone_id` |
| `cloudflare-api_list_ssl_certificates` | List SSL certificate packs for zone(s). | optional `summary_only`, `zone_id` |
| `cloudflare-api_list_ua_rules` | List User-Agent blocking rules for a zone. | optional `summary_only`, `zone_id` |
| `cloudflare-api_list_waf_packages` | List legacy WAF packages for a zone (or all zones if zone_id omitted). | optional `summary_only`, `zone_id` |
| `cloudflare-api_list_zone_ip_access_rules` | List zone-level IP access rules (allow/block) with internal pagination. | optional `summary_only`, `zone_id` |
| `cloudflare-api_list_zone_lockdowns` | List Zone Lockdown rules for a zone (or all zones). | optional `summary_only`, `zone_id` |
| `cloudflare-api_list_zones` | List Cloudflare zones (domains) in scope for the token, or all if not filtered. | optional `summary_only` |

## Datadog

36 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `datadog_cancel_downtime` | Cancel a Datadog downtime | **required** `downtime_id` |
| `datadog_create_dashboard` | Create a new Datadog dashboard | **required** `title`, `layout_type`, `widgets`<br />optional `description`, `notify_list`, `tags`, `template_variables` |
| `datadog_create_downtime` | Create a downtime in Datadog | **required** `scope`, `start`<br />optional `end`, `message`, `monitor_id`, `monitor_tags`, `recurrence`, `timezone` |
| `datadog_create_event` | Create an event in Datadog | **required** `title`, `text`<br />optional `aggregation_key`, `alert_type`, `date_happened`, `host`, `priority`, `related_event_id`, `source_type_name`, `tags` |
| `datadog_create_monitor` | Create a new Datadog monitor | **required** `name`, `monitor_type`, `query`<br />optional `message`, `options`, `priority`, `tags` |
| `datadog_delete_dashboard` | Delete a Datadog dashboard | **required** `dashboard_id` |
| `datadog_delete_monitor` | Delete a Datadog monitor | **required** `monitor_id`<br />optional `force` |
| `datadog_get_dashboard` | Get details of a specific Datadog dashboard | **required** `dashboard_id` |
| `datadog_get_downtime` | Get details of a specific Datadog downtime | **required** `downtime_id` |
| `datadog_get_event` | Get details of a specific Datadog event | **required** `event_id` |
| `datadog_get_logs_aggregates` | Get aggregated logs data from Datadog | **required** `query`, `from_time`, `to`<br />optional `compute`, `group_by`, `timezone` |
| `datadog_get_metric_metadata` | Get metadata for a specific metric | **required** `metric_name` |
| `datadog_get_monitor` | Get details of a specific Datadog monitor | **required** `monitor_id`<br />optional `group_states`, `with_downtimes` |
| `datadog_get_usage_analyzed_logs` | Get analyzed logs usage from Datadog | **required** `start_hr`<br />optional `end_hr` |
| `datadog_get_usage_hosts` | Get host usage from Datadog | **required** `start_hr`<br />optional `end_hr` |
| `datadog_get_usage_logs` | Get logs usage from Datadog | **required** `start_hr`<br />optional `end_hr` |
| `datadog_get_usage_network_hosts` | Get network hosts usage from Datadog | **required** `start_hr`<br />optional `end_hr` |
| `datadog_get_usage_summary` | Get usage summary from Datadog | **required** `start_month`<br />optional `end_month`, `include_org_details` |
| `datadog_get_usage_synthetics` | Get synthetics usage from Datadog | **required** `start_hr`<br />optional `end_hr` |
| `datadog_get_usage_timeseries` | Get timeseries usage from Datadog | **required** `start_hr`<br />optional `end_hr` |
| `datadog_list_dashboards` | List all Datadog dashboards | optional `count`, `filter_deleted`, `filter_shared`, `start` |
| `datadog_list_downtimes` | List all Datadog downtimes | optional `current_only`, `with_creator` |
| `datadog_list_events` | List events in Datadog | **required** `start`, `end`<br />optional `exclude_aggregate`, `page`, `priority`, `sources`, `tags`, `unaggregated` |
| `datadog_list_metrics` | List available metrics in Datadog | optional `query` |
| `datadog_list_monitors` | List all Datadog monitors | optional `group_states`, `id_offset`, `monitor_tags`, `name`, `page`, `page_size`, `tags`, `with_downtimes` |
| `datadog_query_metrics` | Query metrics from Datadog | **required** `query`, `from_ts`, `to` |
| `datadog_query_timeseries_points` | Query timeseries data points from Datadog | **required** `query`, `from_ts`, `to`<br />optional `interval` |
| `datadog_search_logs` | Search for logs in Datadog | **required** `query`, `from_time`, `to`<br />optional `paginate`, `sort`, `timezone` |
| `datadog_submit_logs` | Submit logs to Datadog | **required** `logs` |
| `datadog_submit_metrics` | Submit metrics to Datadog | **required** `series` |
| `datadog_submit_service_checks` | Submit multiple service checks to Datadog | **required** `service_checks` |
| `datadog_update_dashboard` | Update an existing Datadog dashboard | **required** `dashboard_id`, `title`, `layout_type`, `widgets`<br />optional `description`, `notify_list`, `tags`, `template_variables` |
| `datadog_update_downtime` | Update an existing Datadog downtime | **required** `downtime_id`<br />optional `end`, `message`, `monitor_id`, `monitor_tags`, `scope`, `start`, `timezone` |
| `datadog_update_metric_metadata` | Update metadata for a specific metric | **required** `metric_name`<br />optional `description`, `metric_type`, `per_unit`, `short_name`, `statsd_interval`, `unit` |
| `datadog_update_monitor` | Update an existing Datadog monitor | **required** `monitor_id`<br />optional `message`, `monitor_type`, `name`, `options`, `priority`, `query`, `tags` |
| `datadog_validate_monitor` | Validate a Datadog monitor definition (type and query) | **required** `monitor_type`, `query` |

## Dynatrace

0 tools. Available as 2 connections: Dynatrace (OAuth) (OAuth 2.0 client credentials), Dynatrace (Platform Token) (API key).

## FireMon

13 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `firemon_create_policy_planner_ticket` | Create a new policy change request ticket (packet) in FireMon Policy Planner under a specific workflow | **required** `workflow_id`, `subject`, `requester_name`, `requester_email`<br />optional `domain_id`, `due_date`, `priority` |
| `firemon_get_collector` | Get detailed information and status for a specific FireMon data collector | **required** `collector_id` |
| `firemon_get_device` | Get detailed information about a specific FireMon managed device by ID, including management IP, vendor, and status | **required** `device_id`<br />optional `domain_id` |
| `firemon_get_device_status` | Get connectivity and retrieval status for a specific FireMon managed device | **required** `device_id`<br />optional `domain_id` |
| `firemon_get_latest_revision` | Get the most recent successful configuration revision for a FireMon managed device | **required** `device_id`<br />optional `domain_id` |
| `firemon_get_policy_planner_ticket` | Get detailed information about a specific FireMon policy planner ticket (packet) by ID | **required** `ticket_id`, `workflow_id`<br />optional `domain_id` |
| `firemon_get_rule_usage` | Get rule hit count and usage statistics for a FireMon managed device. Returns total rule usage stats. | **required** `device_id`<br />optional `domain_id`, `page`, `page_size` |
| `firemon_list_collectors` | List data collectors and their status in FireMon | — |
| `firemon_list_device_revisions` | List configuration revisions for a FireMon managed device | **required** `device_id`<br />optional `domain_id`, `page`, `page_size` |
| `firemon_list_devices` | List managed devices (firewalls, routers, switches) in FireMon with filtering by name, vendor, or IP | optional `domain_id`, `mgmt_ip`, `name`, `page`, `page_size`, `vendor` |
| `firemon_list_domains` | List configured domains in FireMon Security Manager | optional `page`, `page_size` |
| `firemon_list_policy_planner_tickets` | List policy planner tickets (packets) for a specific workflow in FireMon. Requires a workflow ID. | **required** `workflow_id`<br />optional `domain_id`, `page`, `page_size` |
| `firemon_search_security_rules` | Search security rules across devices using FireMon's SIQL (Security Intelligence Query Language). Examples: 'action = allow', 'source network = 10.0.0.0/8', 'rule unused > 90' | **required** `query`<br />optional `domain_id`, `page`, `page_size` |

## Grafana

21 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `grafana_get_dashboard` | Get dashboard configuration and panel details by UID | **required** `uid` |
| `grafana_get_data_source` | Get specific data source details by ID. This tool is vital to conduct any Grafana investigation, as data source UIDs are required to run any queries. | **required** `id` |
| `grafana_get_health` | Check Grafana instance health and availability | — |
| `grafana_get_trace_by_id` | Get detailed information about a specific trace by its ID | **required** `dataSourceUid`, `traceId` |
| `grafana_list_dashboards` | List available dashboards with optional search filtering | optional `limit`, `query` |
| `grafana_list_data_sources` | List all configured data sources in Grafana. This tool is vital to conduct any Grafana investigation, as data source UIDs are required to run any queries. | — |
| `grafana_list_folders` | List dashboard folders for organization structure | optional `limit` |
| `grafana_list_loki_label_names` | List all available label names in Loki within an optional time range | **required** `dataSourceUid`<br />optional `end`, `start` |
| `grafana_list_loki_label_values` | Get available values for a specific label name in Loki | **required** `dataSourceUid`, `labelName`<br />optional `end`, `start` |
| `grafana_list_prometheus_label_names` | List label names in Prometheus with optional filtering by series selectors and time range | **required** `dataSourceUid`<br />optional `endRfc3339`, `limit`, `matches`, `startRfc3339` |
| `grafana_list_prometheus_label_values` | Get values for a specific label name in Prometheus with optional filtering | **required** `dataSourceUid`, `labelName`<br />optional `endRfc3339`, `limit`, `matches`, `startRfc3339` |
| `grafana_list_prometheus_metric_metadata` | Get metadata about Prometheus metrics including type, help text, and units | **required** `dataSourceUid`<br />optional `limit`, `limitPerMetric`, `metric` |
| `grafana_list_prometheus_metric_names` | List metric names in Prometheus with optional regex filtering and pagination | **required** `dataSourceUid`<br />optional `limit`, `page`, `regex` |
| `grafana_query_loki_logs` | Execute LogQL queries to retrieve logs from Loki. Returns log entries with timestamps, labels, and either log lines or metric values. Supports full LogQL syntax | **required** `dataSourceUid`, `logQL`<br />optional `direction`, `end`, `limit`, `start` |
| `grafana_query_loki_stats` | Get statistics about a LogQL query including bytes and lines processed | **required** `dataSourceUid`, `logQL`<br />optional `end`, `start` |
| `grafana_query_prometheus` | Query Prometheus using PromQL expressions. Supports both instant queries (single point in time) and range queries (time series). | **required** `dataSourceUid`, `expr`, `startTime`<br />optional `endTime`, `queryType`, `stepSeconds` |
| `grafana_query_tempo` | Query traces from Tempo using TraceQL. Returns matching traces with their spans | **required** `dataSourceUid`, `query`, `start`, `end`<br />optional `limit`, `spss`, `step` |
| `grafana_search_annotations` | Search for annotations and events for APM correlation | optional `alertId`, `dashboardId`, `from`, `limit`, `panelId`, `tags`, `to` |
| `grafana_search_metrics` | Search available metrics and resources | **required** `query`<br />optional `limit`, `type` |
| `grafana_search_tempo_tag_values` | Get available values for a specific tag in Tempo | **required** `dataSourceUid`, `tagName`<br />optional `end`, `query`, `start` |
| `grafana_search_tempo_tags` | Search available tags in Tempo | **required** `dataSourceUid` |

## Harness

11 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `harness_abort_pipeline_execution` | Abort (or mark-as-failed) a running pipeline execution. This is a mutating action that interrupts an in-progress run. | **required** `org_id`, `project_id`, `plan_execution_id`<br />optional `interrupt_type` |
| `harness_get_pipeline` | Get a single pipeline's metadata and full YAML definition by its identifier. | **required** `org_id`, `project_id`, `pipeline_id` |
| `harness_get_pipeline_execution` | Get full details of a single pipeline execution by its planExecutionId, including stage/step breakdown and failure info. Use this to debug why a run failed. | **required** `org_id`, `project_id`, `plan_execution_id` |
| `harness_get_pipeline_runtime_inputs` | Fetch the runtime input template (YAML) for a pipeline. The template shows the '&lt;+input>' placeholders that must be supplied as inputs_yaml when calling run_pipeline. Call this first when a pipeline has runtime inputs. | **required** `org_id`, `project_id`, `pipeline_id` |
| `harness_list_environments` | List Harness environments in a project (deploy destinations). | **required** `org_id`, `project_id`<br />optional `page`, `search_term`, `size` |
| `harness_list_organizations` | List Harness organizations in the account. Use this to discover the orgIdentifier needed by project and pipeline tools. | optional `page`, `search_term`, `size` |
| `harness_list_pipeline_executions` | List pipeline executions (runs) in a project, optionally filtered by a specific pipeline. Returns execution summaries including status and the planExecutionId used by get_pipeline_execution. | **required** `org_id`, `project_id`<br />optional `page`, `pipeline_id`, `search_term`, `size` |
| `harness_list_pipelines` | List pipelines in a Harness project, with optional search and module (ci/cd) filtering. | **required** `org_id`, `project_id`<br />optional `module`, `page`, `search_term`, `size` |
| `harness_list_projects` | List Harness projects, optionally scoped to an organization. Use this to discover the projectIdentifier needed by pipeline tools. | optional `org_id`, `page`, `search_term`, `size` |
| `harness_list_services` | List Harness services in a project (deployment targets). | **required** `org_id`, `project_id`<br />optional `page`, `search_term`, `size` |
| `harness_run_pipeline` | Trigger (execute) a pipeline. This is a mutating action that starts a real CI/CD run. If the pipeline has runtime inputs, first call get_pipeline_runtime_inputs and pass the filled-in YAML as inputs_yaml. | **required** `org_id`, `project_id`, `pipeline_id`<br />optional `inputs_yaml`, `module`, `notes` |

## Microsoft Azure

18 tools. Available as 4 connections: Microsoft Azure (OAuth 2.0), Microsoft Azure (Application) (OAuth 2.0 client credentials), Microsoft Azure (Government) (OAuth 2.0), Microsoft Azure (Government, Application) (OAuth 2.0 client credentials).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-azure_get_management_group` | Get a single Azure management group by ID. Optionally expand its child management groups and subscriptions recursively. | **required** `group_id`<br />optional `expand_children` |
| `microsoft-azure_get_policy_assignment` | Get a single Azure Policy assignment by name at a scope. Returns the assignment's policy definition reference, parameters, and enforcement mode. | **required** `assignment_name`<br />optional `scope`, `subscription_id` |
| `microsoft-azure_get_policy_compliance_summary` | Summarize Azure Policy compliance for a subscription, optionally scoped to a single policy assignment. Returns aggregated compliant vs non-compliant counts by policy assignment and definition. | optional `policy_assignment_name`, `subscription_id` |
| `microsoft-azure_get_policy_definition` | Get a single Azure Policy definition by name within a subscription. Returns the definition's rule, parameters, and metadata. | **required** `definition_name`<br />optional `subscription_id` |
| `microsoft-azure_get_role_assignment` | Get a single Azure RBAC role assignment by name at a scope. Returns the assigned principal, role definition ID, and scope. | **required** `role_assignment_name`<br />optional `scope`, `subscription_id` |
| `microsoft-azure_get_role_definition` | Get a single Azure RBAC role definition by ID at a scope. Returns the role's name, description, and actions/notActions/dataActions permission sets. | **required** `role_definition_id`<br />optional `scope`, `subscription_id` |
| `microsoft-azure_get_subscription` | Get details for a single Azure subscription by its subscription ID, including display name, state, and tenant ID. | **required** `subscription_id` |
| `microsoft-azure_list_management_group_descendants` | List the flattened descendant tree of a management group, including nested management groups and subscriptions beneath it. | **required** `group_id`<br />optional `top` |
| `microsoft-azure_list_management_groups` | List the Azure management groups visible to the authenticated identity. Management groups organize subscriptions into a governance hierarchy. | — |
| `microsoft-azure_list_noncompliant_resources` | List resources that are currently non-compliant with Azure Policy in a subscription. Returns the latest policy state records filtered to ComplianceState eq 'NonCompliant'. | optional `subscription_id`, `top` |
| `microsoft-azure_list_policy_assignments` | List Azure Policy assignments at a scope. Provide an explicit ARM scope (subscription, resource group, or management group ID) or fall back to the configured subscription. | optional `odata_filter`, `scope`, `subscription_id`, `top` |
| `microsoft-azure_list_policy_definitions` | List Azure Policy definitions (built-in and custom) available at a scope. Provide an explicit ARM scope or fall back to the configured subscription. | optional `scope`, `subscription_id`, `top` |
| `microsoft-azure_list_resource_groups` | List resource groups in a subscription. Returns each group's name, location, and tags. Defaults to the connection's configured subscription when subscription_id is omitted. | optional `subscription_id` |
| `microsoft-azure_list_resources` | List Azure resources in a subscription, optionally narrowed to a single resource group. Supports an OData $filter (e.g. "resourceType eq 'Microsoft.Compute/virtualMachines'") and a result cap. | optional `odata_filter`, `resource_group`, `subscription_id`, `top` |
| `microsoft-azure_list_role_assignments` | List Azure RBAC role assignments at a scope. Optionally filter by principal (user/group/service principal object ID) and/or restrict to assignments defined directly at the scope (atScope()). | optional `at_scope`, `principal_id`, `scope`, `subscription_id`, `top` |
| `microsoft-azure_list_role_definitions` | List Azure RBAC role definitions available at a scope. Optionally restrict to custom roles only. Returns role names, descriptions, and their actions/notActions/dataActions permission sets. | optional `custom_only`, `scope`, `subscription_id`, `top` |
| `microsoft-azure_list_subscriptions` | List all Azure subscriptions the authenticated identity can access within the tenant. Returns subscription IDs, display names, and state. Use this to discover which subscriptions to target with other tools. | — |
| `microsoft-azure_query_resources` | Run an Azure Resource Graph (KQL) query across one or more subscriptions or management groups. | **required** `query`<br />optional `limit`, `management_groups`, `subscriptions`, `top` |

## Nagios XI

14 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `nagios-xi_cancel_downtime` | Cancel a scheduled downtime entry by its downtime ID (from list_downtime). | **required** `downtime_id` |
| `nagios-xi_get_contacts` | Get contact definitions — who gets notified. Omit contact_name for all contacts. | optional `contact_name` |
| `nagios-xi_get_host_status` | — | optional `host_name` |
| `nagios-xi_get_hostgroups` | Get host group definitions. Omit hostgroup_name for all groups. | optional `hostgroup_name` |
| `nagios-xi_get_hosts` | Get host configuration definitions — address, check settings, templates. Omit host_name for all hosts. | optional `host_name` |
| `nagios-xi_get_log_entries` | Get recent monitoring log / alert events. Filter by host_name and a Unix-timestamp time window (start_time / end_time). | optional `end_time`, `host_name`, `start_time` |
| `nagios-xi_get_service_status` | — | optional `host_name`, `service_description` |
| `nagios-xi_get_servicegroups` | Get service group definitions. Omit servicegroup_name for all groups. | optional `servicegroup_name` |
| `nagios-xi_get_services` | Get service configuration definitions. Filter by host_name and/or service_description. | optional `host_name`, `service_description` |
| `nagios-xi_get_state_history` | Get the historical state-change trail for hosts/services — the audit of when state transitions happened. Filter by host_name and/or service_description. | optional `host_name`, `service_description` |
| `nagios-xi_list_comments` | List comments recorded on hosts and services. Filter by host_name and/or service_description. | optional `host_name`, `service_description` |
| `nagios-xi_list_downtime` | List scheduled downtime entries for hosts and services. | — |
| `nagios-xi_list_problems` | List every host and service NOT in an OK/UP state — the triage workhorse. Returns host_problems and service_problems with counts. | optional `host_name` |
| `nagios-xi_schedule_downtime` | Schedule a downtime window on hosts, host groups, and/or service groups. start_time and end_time are Unix timestamps (epoch seconds). At least one target — individual hosts, host groups, or service groups — must be provided. | **required** `comment`, `start_time`, `end_time`<br />optional `host_names`, `hostgroup_names`, `servicegroup_names` |

## Palo Alto NGFW

15 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `palo-alto-ngfw_commit_changes` | Commit the PAN-OS candidate configuration to running config. Returns the commit job ID for tracking. | optional `description`, `force` |
| `palo-alto-ngfw_create_address_group` | Create a new PAN-OS address group (static with member list or dynamic with filter) | **required** `name`<br />optional `description`, `device_group`, `dynamic_filter`, `location`, `static`, `tag`, `vsys` |
| `palo-alto-ngfw_create_address_object` | Create a new PAN-OS address object (IP netmask, IP range, or FQDN) | **required** `name`, `address_type`, `value`<br />optional `description`, `device_group`, `location`, `tag`, `vsys` |
| `palo-alto-ngfw_create_nat_rule` | Create a new PAN-OS NAT rule with source/destination translation | **required** `name`, `source`, `destination`, `source_zone`<br />optional `description`, `destination_translation`, `destination_zone`, `device_group`, `disabled`, `location`, `service`, `source_translation`, `tag`, `vsys` |
| `palo-alto-ngfw_create_security_rule` | Create a new PAN-OS security policy rule with source, destination, zones, application, service, and action | **required** `name`, `source`, `destination`, `source_zone`, `destination_zone`, `application`, `service`<br />optional `action`, `description`, `device_group`, `disabled`, `location`, `log_end`, `log_start`, `tag`, `vsys` |
| `palo-alto-ngfw_delete_address_object` | Delete a PAN-OS address object by name | **required** `name`<br />optional `device_group`, `location`, `vsys` |
| `palo-alto-ngfw_get_job_status` | Check the status of a PAN-OS commit or push job by job ID | **required** `job_id` |
| `palo-alto-ngfw_get_nat_rule` | Get a specific PAN-OS NAT rule by name | **required** `name`<br />optional `device_group`, `location`, `vsys` |
| `palo-alto-ngfw_get_security_rule` | Get a specific PAN-OS security rule by name | **required** `name`<br />optional `device_group`, `location`, `vsys` |
| `palo-alto-ngfw_get_system_info` | Get PAN-OS firewall system information including model, software version, serial number, and uptime | — |
| `palo-alto-ngfw_list_address_groups` | List PAN-OS address groups (static and dynamic) | optional `device_group`, `location`, `vsys` |
| `palo-alto-ngfw_list_address_objects` | List PAN-OS address objects (IP, FQDN, range) with optional location filtering | optional `device_group`, `location`, `vsys` |
| `palo-alto-ngfw_list_nat_rules` | List PAN-OS NAT policy rules with location/vsys/device-group filtering | optional `device_group`, `location`, `vsys` |
| `palo-alto-ngfw_list_security_rules` | List PAN-OS security policy rules with location/vsys/device-group filtering | optional `device_group`, `location`, `vsys` |
| `palo-alto-ngfw_update_security_rule` | Update an existing PAN-OS security rule's properties (source, destination, action, etc.) | **required** `name`<br />optional `action`, `application`, `description`, `destination`, `destination_zone`, `device_group`, `disabled`, `location`, `log_end`, `log_start`, `service`, `source`, `source_zone`, `tag`, `vsys` |

## Supabase

0 tools. Connect with OAuth 2.0.

## Zabbix

10 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `zabbix_acknowledge_event` | — | **required** `event_ids`<br />optional `actions`, `message`, `severity` |
| `zabbix_get_host` | Fetch a single host by ID with full interfaces, groups, and tags. | **required** `host_id` |
| `zabbix_get_item_history` | Fetch time-series history values for a single item. `value_type` MUST match the item's stored value type (see list_items.value_type). | **required** `item_id`, `value_type`<br />optional `limit`, `time_from`, `time_until` |
| `zabbix_get_trigger` | Fetch a single trigger by ID with its expression and host context. | **required** `trigger_id` |
| `zabbix_list_events` | List historical events with filters for source, time range, host(s), and severity. | optional `host_ids`, `limit`, `min_severity`, `source`, `time_from`, `time_until` |
| `zabbix_list_host_groups` | List host groups (used as the input filter for list_hosts). | optional `limit`, `search` |
| `zabbix_list_hosts` | List monitored hosts. Filter by host group, name search, and monitored/unmonitored status. | optional `group_ids`, `limit`, `search`, `status` |
| `zabbix_list_items` | List monitored items (metrics) for one or more hosts. Each item has a `value_type` that determines which history table backs it. | optional `host_ids`, `limit`, `only_enabled`, `search` |
| `zabbix_list_problems` | List CURRENT open problems (the SOC workhorse view). Filter by host, host group, minimum severity, and acknowledged status. | optional `acknowledged`, `group_ids`, `host_ids`, `limit`, `min_severity` |
| `zabbix_list_triggers` | List trigger (alert-rule) definitions. Useful for investigation: 'why did this fire?'. | optional `group_ids`, `host_ids`, `limit`, `min_severity`, `only_enabled`, `search` |

---

## Service and incident

Source: https://docs.kindo.ai/reference/tool-catalog/service-incident/

:::note[Beta]
The tool catalog is in beta and is a point-in-time snapshot of the integration inventory, so an entry can differ from what your organization sees in product.
:::

Ticketing, on-call, and service-desk platforms an agent can triage and update. 6 integrations, 214 tools.

Tool names below are the fully qualified names an agent sees once the integration is connected. Where an integration offers more than one connection, the names shown use the primary connection's prefix; connecting through another variant prefixes its tools with that variant's own integration ID instead. See [Tool Catalog](/reference/tool-catalog/) for how tools are granted and named.

## FireHydrant

12 tools. Connect with API key.

| Tool | Description | Arguments |
| --- | --- | --- |
| `firehydrant_create_incident` | Create a new FireHydrant incident with name, severity, teams, alerts, and tags | **required** `name`<br />optional `alert_ids`, `customer_impact_summary`, `description`, `incident_type_id`, `priority`, `restricted`, `runbook_ids`, `severity`, `summary`, `tag_list`, `team_ids` |
| `firehydrant_get_alert` | Get a single FireHydrant alert by ID | **required** `alert_id` |
| `firehydrant_get_incident` | Get a single FireHydrant incident by ID | **required** `incident_id` |
| `firehydrant_get_service` | Get a single FireHydrant service by UUID or slug | **required** `service_id` |
| `firehydrant_list_alerts` | List FireHydrant alerts with filters for services, teams, environments, and status | optional `environments`, `page`, `per_page`, `query`, `services`, `statuses`, `teams` |
| `firehydrant_list_environments` | List FireHydrant environments with search filters | optional `name`, `page`, `per_page`, `query` |
| `firehydrant_list_incidents` | List FireHydrant incidents with filters for services, teams, environments, severity, and status | optional `assigned_teams`, `environments`, `page`, `per_page`, `query`, `services`, `severities`, `status`, `teams` |
| `firehydrant_list_retrospectives_for_incident` | List retrospectives attached to a FireHydrant incident | **required** `incident_id`<br />optional `page`, `per_page` |
| `firehydrant_list_services` | List FireHydrant services with label, owner, tier, team, and functionality filters | optional `available_downstream_dependencies_for_id`, `available_upstream_dependencies_for_id`, `functionalities`, `impacted`, `include`, `labels`, `lite`, `name`, `owner`, `page`, `per_page`, `query`, `responding_teams`, `tiers` |
| `firehydrant_list_teams` | List FireHydrant teams with search, service, and role filters | optional `default_incident_role`, `lite`, `name`, `page`, `per_page`, `query`, `services` |
| `firehydrant_update_incident` | Update a FireHydrant incident's name, summary, severity, priority, or tags | **required** `incident_id`<br />optional `customer_impact_summary`, `description`, `incident_type_id`, `name`, `priority`, `severity`, `summary`, `tag_list` |
| `firehydrant_update_retrospective_field` | Update the value of a field on a FireHydrant incident retrospective | **required** `incident_id`, `retrospective_id`, `field_id`, `value`<br />optional `dynamic_input_field_id` |

## Freshdesk

59 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `freshdesk_create_agent` | Create a Freshdesk agent using a top-level agent payload. | **required** `email`<br />optional `additional_fields`, `contact`, `group_ids`, `occasional`, `role_ids`, `skill_ids`, `ticket_scope` |
| `freshdesk_create_canned_response` | Create a Freshdesk canned response. Required fields: title, content_html, folder_id. Optional: visibility (1=all agents, 2=specific groups). | **required** `title`, `content_html`, `folder_id`<br />optional `visibility` |
| `freshdesk_create_canned_response_folder` | Create a Freshdesk canned response folder. | **required** `name` |
| `freshdesk_create_contact_field` | Create a Freshdesk contact field using a top-level field payload. | **required** `label_for_customers`, `contact_field_type`<br />optional `choices`, `customers_can_edit`, `displayed_for_customers`, `editable_in_signup`, `label`, `position`, `required_for_agents`, `required_for_customers` |
| `freshdesk_create_group` | Create a Freshdesk group using a top-level group payload. | **required** `name`<br />optional `agent_ids`, `auto_ticket_assign`, `description`, `escalate_to`, `unassigned_for` |
| `freshdesk_create_solution_article` | Create a Freshdesk solution article within a folder using a top-level article payload. | **required** `folder_id`, `article_title`, `description`<br />optional `article_type`, `seo_data`, `status`, `tags` |
| `freshdesk_create_solution_category` | Create a Freshdesk solution category using a top-level category payload. | **required** `name`<br />optional `description` |
| `freshdesk_create_solution_category_folder` | Create a Freshdesk solution folder within a category using a top-level folder payload. | **required** `category_id`, `name`<br />optional `description`, `visibility` |
| `freshdesk_create_ticket` | Create a Freshdesk ticket with requester information, priority, source, status, and optional custom fields. | optional `additional_fields`, `custom_fields`, `description`, `email`, `phone`, `priority`, `requester_id`, `source`, `status`, `subject` |
| `freshdesk_create_ticket_field` | Create a Freshdesk ticket field using a top-level field payload. | **required** `label_for_customers`, `ticket_field_type`<br />optional `choices`, `customers_can_edit`, `displayed_to_customers`, `label`, `position`, `required_for_agents`, `required_for_closure`, `required_for_customers` |
| `freshdesk_create_ticket_note` | Create an internal note on a Freshdesk ticket using an HTML body. | **required** `ticket_id`, `body` |
| `freshdesk_create_ticket_reply` | Create a public reply on a Freshdesk ticket using an HTML body. | **required** `ticket_id`, `body` |
| `freshdesk_delete_ticket` | Delete a Freshdesk ticket by ID. | **required** `ticket_id` |
| `freshdesk_delete_ticket_summary` | Delete the summary associated with a Freshdesk ticket. | **required** `ticket_id` |
| `freshdesk_find_company_by_name` | Find the best Freshdesk company match for a given company name. | **required** `name` |
| `freshdesk_get_agents` | List Freshdesk agents with page-based pagination. | optional `page`, `per_page` |
| `freshdesk_get_contact` | Get a single Freshdesk contact by ID. | **required** `contact_id` |
| `freshdesk_get_field_properties` | Return the Freshdesk ticket field definition for a specific field name. | **required** `field_name` |
| `freshdesk_get_ticket` | Get a single Freshdesk ticket by ID. | **required** `ticket_id` |
| `freshdesk_get_ticket_conversation` | List conversations for a Freshdesk ticket. | **required** `ticket_id` |
| `freshdesk_get_ticket_fields` | List Freshdesk ticket fields, including built-in and custom fields. | — |
| `freshdesk_get_tickets` | List Freshdesk tickets with page-based pagination. | optional `page`, `per_page` |
| `freshdesk_list_canned_response_folders` | List Freshdesk canned response folders. | — |
| `freshdesk_list_canned_responses` | List Freshdesk canned responses in a folder. | **required** `folder_id` |
| `freshdesk_list_companies` | List Freshdesk companies with page-based pagination. | optional `page`, `per_page` |
| `freshdesk_list_company_fields` | List Freshdesk company field definitions. | — |
| `freshdesk_list_contact_fields` | List Freshdesk contact field definitions. | — |
| `freshdesk_list_contacts` | List Freshdesk contacts with page-based pagination. | optional `page`, `per_page` |
| `freshdesk_list_groups` | List Freshdesk groups with page-based pagination. | optional `page`, `per_page` |
| `freshdesk_list_solution_articles` | List Freshdesk solution articles within a folder. | **required** `folder_id` |
| `freshdesk_list_solution_categories` | List Freshdesk solution categories. | — |
| `freshdesk_list_solution_folders` | List Freshdesk solution folders within a category. | **required** `category_id` |
| `freshdesk_search_agents` | Search Freshdesk agents by autocomplete term. | **required** `query` |
| `freshdesk_search_companies` | Search Freshdesk companies by company name. | **required** `query` |
| `freshdesk_search_contacts` | Search Freshdesk contacts by autocomplete term. | **required** `query` |
| `freshdesk_search_tickets` | Search Freshdesk tickets using filter query syntax. Valid search fields: priority, status, type, tag, due_by, fr_due_by, created_at, updated_at, group_id, requester_id, company_id, agent_id. | **required** `query` |
| `freshdesk_update_agent` | Update a Freshdesk agent using a top-level agent payload. | **required** `agent_id`<br />optional `additional_fields`, `contact`, `group_ids`, `occasional`, `role_ids`, `skill_ids`, `ticket_scope` |
| `freshdesk_update_canned_response` | Update a Freshdesk canned response. Supported fields: title, content_html, folder_id, visibility. | **required** `canned_response_id`<br />optional `content_html`, `folder_id`, `title`, `visibility` |
| `freshdesk_update_canned_response_folder` | Update the name of a Freshdesk canned response folder. | **required** `folder_id`, `name` |
| `freshdesk_update_contact` | Update top-level Freshdesk contact fields for a specific contact. | **required** `contact_id`<br />optional `additional_fields`, `address`, `company_id`, `custom_fields`, `description`, `email`, `job_title`, `language`, `mobile`, `name`, `phone`, `tags`, `time_zone`, `unique_external_id` |
| `freshdesk_update_contact_field` | Update a Freshdesk contact field using a top-level field payload. | **required** `contact_field_id`<br />optional `choices`, `customers_can_edit`, `displayed_for_customers`, `editable_in_signup`, `label`, `label_for_customers`, `position`, `required_for_agents`, `required_for_customers` |
| `freshdesk_update_group` | Update top-level Freshdesk group fields for a specific group. | **required** `group_id`<br />optional `agent_ids`, `auto_ticket_assign`, `description`, `escalate_to`, `name`, `unassigned_for` |
| `freshdesk_update_solution_article` | Update a Freshdesk solution article using a top-level article payload. | **required** `article_id`<br />optional `article_title`, `article_type`, `description`, `seo_data`, `status`, `tags` |
| `freshdesk_update_solution_category` | Update a Freshdesk solution category using a top-level category payload. | **required** `category_id`<br />optional `description`, `name` |
| `freshdesk_update_solution_category_folder` | Update a Freshdesk solution folder using a top-level folder payload. | **required** `folder_id`<br />optional `description`, `name`, `visibility` |
| `freshdesk_update_ticket` | Update top-level Freshdesk ticket fields for a specific ticket ID. | **required** `ticket_id`<br />optional `additional_fields`, `custom_fields`, `description`, `due_by`, `email`, `group_id`, `priority`, `requester_id`, `responder_id`, `source`, `status`, `subject`, `tags`, `ticket_type` |
| `freshdesk_update_ticket_conversation` | Update an existing Freshdesk ticket conversation body. | **required** `conversation_id`, `body` |
| `freshdesk_update_ticket_field` | Update a Freshdesk ticket field using a top-level field payload. | **required** `ticket_field_id`<br />optional `choices`, `customers_can_edit`, `displayed_to_customers`, `label`, `label_for_customers`, `position`, `required_for_agents`, `required_for_closure`, `required_for_customers` |
| `freshdesk_update_ticket_summary` | Update the Freshdesk ticket summary body. | **required** `ticket_id`, `body` |
| `freshdesk_view_agent` | Get a single Freshdesk agent by ID. | **required** `agent_id` |
| `freshdesk_view_canned_response` | Get a single Freshdesk canned response by ID. | **required** `canned_response_id` |
| `freshdesk_view_company` | Get a single Freshdesk company by ID. | **required** `company_id` |
| `freshdesk_view_contact_field` | Get a single Freshdesk contact field definition by ID. | **required** `contact_field_id` |
| `freshdesk_view_group` | Get a single Freshdesk group by ID. | **required** `group_id` |
| `freshdesk_view_solution_article` | Get a single Freshdesk solution article by ID. | **required** `article_id` |
| `freshdesk_view_solution_category` | Get a single Freshdesk solution category by ID. | **required** `category_id` |
| `freshdesk_view_solution_category_folder` | Get a single Freshdesk solution folder by ID. | **required** `folder_id` |
| `freshdesk_view_ticket_field` | Get a single Freshdesk ticket field definition by ID. | **required** `ticket_field_id` |
| `freshdesk_view_ticket_summary` | Get the AI summary associated with a Freshdesk ticket. | **required** `ticket_id` |

## Freshservice

32 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `freshservice_add_ticket_note` | Add a private or public note to a Freshservice ticket. Notes are internal communications visible to agents (private) or also to requesters (public). | **required** `ticket_id`, `body`<br />optional `private` |
| `freshservice_add_ticket_reply` | Send a reply to the requester on a Freshservice ticket. The reply is sent as an email to the ticket requester. | **required** `ticket_id`, `body` |
| `freshservice_attach_file_to_ticket` | Attach a file to a Freshservice ticket by creating a note (private by default, or public when `private` is false) with the file included. Pass `source_url`: a short-lived signed download URL minted by the `mint_upload_url` tool. | **required** `ticket_id`, `file_name`, `source_url`<br />optional `content_type`, `note_body`, `private` |
| `freshservice_create_change` | Create a new Freshservice change request. Change requests are used to plan and track modifications to IT infrastructure and services. | **required** `subject`, `description`, `requester_id`, `priority`, `status`, `change_type`<br />optional `category`, `department_id`, `group_id`, `impact`, `planned_end_date`, `planned_start_date`, `risk` |
| `freshservice_create_problem` | Create a new Freshservice problem record. Problems track the root cause of one or more incidents. | **required** `subject`, `description`, `requester_id`, `priority`, `status`<br />optional `category`, `department_id`, `group_id`, `impact`, `known_error` |
| `freshservice_create_ticket` | Create a new Freshservice ticket (incident or service request). Requires subject, description, priority, and status. Either email or requester_id must be provided. | **required** `subject`, `description`, `priority`, `status`<br />optional `category`, `department_id`, `email`, `group_id`, `requester_id`, `responder_id`, `source`, `sub_category`, `tags`, `ticket_type` |
| `freshservice_create_ticket_task` | Create a new task within a Freshservice ticket. Tasks represent actionable sub-items of work. | **required** `ticket_id`, `title`<br />optional `description`, `due_date`, `group_id`, `notify_before`, `responder_id`, `status` |
| `freshservice_get_agent` | Get a single Freshservice agent's details by ID. | **required** `agent_id` |
| `freshservice_get_asset` | Get a single IT asset from the Freshservice CMDB by its display ID. | **required** `asset_id` |
| `freshservice_get_change` | Get a single Freshservice change request by ID with full details. | **required** `change_id` |
| `freshservice_get_problem` | Get a single Freshservice problem record by ID with full details. | **required** `problem_id` |
| `freshservice_get_requester` | Get a single Freshservice requester's details by ID. | **required** `requester_id` |
| `freshservice_get_service_catalog_item` | Get details of a specific Freshservice service catalog item, including its field definitions and configuration. Uses the display_id (small integer shown in the catalog list), not the internal ID. | **required** `display_id` |
| `freshservice_get_solution_article` | Get the full content of a Freshservice knowledge base article by ID. | **required** `article_id` |
| `freshservice_get_ticket` | Get a single Freshservice ticket by ID. Optionally include related data like conversations, requester, stats, problem, assets, or tags. | **required** `ticket_id`<br />optional `include` |
| `freshservice_list_agents` | List Freshservice helpdesk agents with optional filtering by email, active status, or state. | optional `active`, `email`, `page`, `per_page`, `state` |
| `freshservice_list_assets` | List IT assets in the Freshservice CMDB with pagination. | optional `page`, `per_page` |
| `freshservice_list_changes` | List Freshservice change requests with optional filtering and pagination. Change requests track planned modifications to IT infrastructure. | optional `filter_query`, `order_by`, `order_type`, `page`, `per_page`, `updated_since` |
| `freshservice_list_departments` | List Freshservice departments. Departments represent organizational units. | optional `page`, `per_page` |
| `freshservice_list_groups` | List Freshservice agent groups. Groups organize agents by team or function. | optional `page`, `per_page` |
| `freshservice_list_problems` | List Freshservice problem records with optional filtering and pagination. Problems represent recurring or underlying issues causing incidents. | optional `order_by`, `order_type`, `page`, `per_page`, `updated_since` |
| `freshservice_list_requested_items` | List requested items for a Freshservice service request ticket. Returns the service catalog form fields and values submitted by the requester. Returns 404 for non-existent or otherwise inaccessible tickets. | **required** `ticket_id`<br />optional `page`, `per_page` |
| `freshservice_list_requesters` | List Freshservice requesters (end users who submit tickets) with optional email filtering. | optional `email`, `page`, `per_page` |
| `freshservice_list_service_catalog_items` | List available service catalog items (forms/services) configured in the Freshservice instance. | optional `page`, `per_page` |
| `freshservice_list_solution_articles` | List Freshservice knowledge base articles within a specific folder. A folder_id is required; folders exist within solution categories. | **required** `folder_id`<br />optional `page`, `per_page` |
| `freshservice_list_solution_categories` | List Freshservice knowledge base solution categories. Categories organize articles into a hierarchy. | optional `page`, `per_page` |
| `freshservice_list_ticket_tasks` | List all tasks associated with a Freshservice ticket. Tasks are sub-items of work within a ticket. | **required** `ticket_id`<br />optional `page`, `per_page` |
| `freshservice_list_tickets` | List Freshservice tickets with optional filtering by predefined filter, requester, ticket type, update timestamp, sort order, and pagination. | optional `email`, `filter_query`, `order_by`, `order_type`, `page`, `per_page`, `requester_id`, `ticket_type`, `updated_since` |
| `freshservice_search_assets` | Search IT assets in the Freshservice CMDB using Freshservice filter syntax. Pass the inner query only; the integration adds the required outer double quotes for the API. | **required** `query`<br />optional `page`, `per_page` |
| `freshservice_update_change` | Update an existing Freshservice change request's properties such as status, priority, or type. | **required** `change_id`<br />optional `category`, `change_type`, `department_id`, `description`, `group_id`, `impact`, `priority`, `risk`, `status`, `subject` |
| `freshservice_update_problem` | Update an existing Freshservice problem record's properties such as status, priority, or known error flag. | **required** `problem_id`<br />optional `category`, `department_id`, `description`, `group_id`, `impact`, `known_error`, `priority`, `status`, `subject` |
| `freshservice_update_ticket` | Update an existing Freshservice ticket's properties such as status, priority, assignee, or description. | **required** `ticket_id`<br />optional `category`, `department_id`, `description`, `group_id`, `priority`, `responder_id`, `status`, `sub_category`, `subject`, `tags`, `ticket_type` |

## PagerDuty

57 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `pagerduty_acknowledge_incident` | Acknowledge an incident in PagerDuty | **required** `id`, `from` |
| `pagerduty_create_incident` | Create a new incident in PagerDuty | **required** `from`, `title`, `service_id`<br />optional `body_details`, `conference_bridge_number`, `conference_bridge_url`, `escalation_policy_id`, `incident_key`, `priority_id`, `urgency` |
| `pagerduty_create_incident_note` | Add a note to an incident in PagerDuty | **required** `id`, `from`, `content` |
| `pagerduty_create_schedule_override` | Create an override on an on-call schedule | **required** `id`, `user_id`, `start`, `end`<br />optional `time_zone` |
| `pagerduty_create_status_page_post` | Create a new post on a status page with an initial update | **required** `id`, `from`, `title`, `post_type`, `message`, `status_id`, `severity_id`<br />optional `ends_at`, `impacted_services`, `notify_subscribers`, `starts_at` |
| `pagerduty_create_status_page_post_update` | Add an update to a status page post | **required** `id`, `post_id`, `from`, `message`, `status_id`, `severity_id`<br />optional `impacted_services`, `notify_subscribers`, `update_frequency_ms` |
| `pagerduty_get_alert_grouping_setting` | Get details of a specific alert grouping setting | **required** `service_id`, `id` |
| `pagerduty_get_change_event` | Get details of a specific change event by ID | **required** `id`<br />optional `include` |
| `pagerduty_get_escalation_policy` | Get details of a specific escalation policy by ID | **required** `id`<br />optional `include` |
| `pagerduty_get_event_orchestration` | Get details of a specific event orchestration by ID | **required** `id`<br />optional `include` |
| `pagerduty_get_event_orchestration_global` | Get global configuration for an event orchestration | **required** `id` |
| `pagerduty_get_event_orchestration_router` | Get router configuration for an event orchestration | **required** `id` |
| `pagerduty_get_event_orchestration_service` | Get service configuration for an event orchestration | **required** `id`, `service_id` |
| `pagerduty_get_incident` | Get details of a specific incident by ID | **required** `id` |
| `pagerduty_get_incident_workflow` | Get details of a specific incident workflow by ID | **required** `id`<br />optional `include` |
| `pagerduty_get_my_data` | Get the current authenticated user profile, including their email address, name, ID, and role | — |
| `pagerduty_get_outlier_incident` | Get outlier incident information for a specific incident | **required** `id` |
| `pagerduty_get_past_incidents` | Get past incidents related to a specific incident | **required** `id` |
| `pagerduty_get_related_incidents` | Get incidents related to a specific incident | **required** `id` |
| `pagerduty_get_schedule` | Get details of a specific schedule by ID | **required** `id`<br />optional `since`, `time_zone`, `until` |
| `pagerduty_get_service` | Get details of a specific service by ID. Use include=["integrations"] to get integrations with their integration_key (routing key) for the Events API. | **required** `id`<br />optional `include` |
| `pagerduty_get_status_page_post` | Get details of a specific status page post | **required** `id`, `post_id`<br />optional `include` |
| `pagerduty_get_team` | Get details of a specific team by ID | **required** `id`<br />optional `include` |
| `pagerduty_get_user` | Get details of a specific user by ID | **required** `id` |
| `pagerduty_list_alert_grouping_settings` | List alert grouping settings for a service | **required** `service_id`<br />optional `limit`, `offset`, `total` |
| `pagerduty_list_change_events` | List recent change events (deployments, releases, config changes) tracked in PagerDuty | optional `filter`, `include`, `limit`, `offset`, `since`, `total`, `until` |
| `pagerduty_list_escalation_policies` | List escalation policies from PagerDuty with optional filtering | optional `include`, `limit`, `offset`, `query`, `sort_by`, `team_ids`, `total` |
| `pagerduty_list_event_orchestrations` | List event orchestrations from PagerDuty | optional `include`, `limit`, `offset`, `query`, `sort_by`, `total` |
| `pagerduty_list_incident_alerts` | List all alerts for a specific incident, including their IDs, statuses, and details | **required** `id`<br />optional `include`, `limit`, `offset`, `sort_by`, `statuses`, `total` |
| `pagerduty_list_incident_change_events` | List change events for a specific incident | **required** `id`<br />optional `limit`, `offset`, `total` |
| `pagerduty_list_incident_notes` | List notes for a specific incident | **required** `id` |
| `pagerduty_list_incident_workflows` | List all incident workflows configured in PagerDuty, including their IDs, names, and trigger conditions | optional `include`, `limit`, `offset`, `query`, `total` |
| `pagerduty_list_incidents` | List incidents from PagerDuty with optional filtering and pagination | optional `date_range`, `incident_key`, `include`, `limit`, `offset`, `service_ids`, `sort_by`, `statuses`, `team_ids`, `total`, `urgencies`, `user_ids` |
| `pagerduty_list_on_calls` | List who is currently on-call, including the user, escalation policy, and escalation level for each assignment | optional `earliest`, `escalation_policy_ids`, `include`, `limit`, `offset`, `schedule_ids`, `since`, `total`, `until`, `user_ids` |
| `pagerduty_list_priorities` | List all priority levels configured in the PagerDuty account (e.g. P1, P2, P3), including their IDs and names | optional `limit`, `offset`, `total` |
| `pagerduty_list_schedule_users` | List users on a schedule | **required** `id`<br />optional `since`, `until` |
| `pagerduty_list_schedules` | List schedules from PagerDuty with optional filtering | optional `include`, `limit`, `offset`, `query`, `team_ids`, `total` |
| `pagerduty_list_service_change_events` | List change events for a specific service | **required** `id`<br />optional `limit`, `offset`, `since`, `total`, `until` |
| `pagerduty_list_services` | List services from PagerDuty with optional filtering | optional `include`, `limit`, `offset`, `sort_by`, `team_ids`, `time_zone`, `total` |
| `pagerduty_list_status_page_impacts` | List available impact levels for a status page | **required** `id` |
| `pagerduty_list_status_page_post_updates` | List updates for a status page post | **required** `id`, `post_id`<br />optional `limit`, `offset`, `total` |
| `pagerduty_list_status_page_posts` | List all posts for a specific status page, including their IDs, titles, and statuses | **required** `id`<br />optional `limit`, `offset`, `total` |
| `pagerduty_list_status_page_severities` | List available severity levels for a status page | **required** `id` |
| `pagerduty_list_status_page_statuses` | List available status values for a status page | **required** `id` |
| `pagerduty_list_status_pages` | List status pages from PagerDuty | optional `include`, `limit`, `offset`, `query`, `total` |
| `pagerduty_list_team_members` | List members of a team | **required** `id`<br />optional `include`, `limit`, `offset`, `total` |
| `pagerduty_list_teams` | List teams from PagerDuty with optional filtering | optional `include`, `limit`, `offset`, `query`, `total` |
| `pagerduty_list_users` | List users from PagerDuty with optional filtering | optional `include`, `limit`, `offset`, `query`, `team_ids`, `total` |
| `pagerduty_merge_incidents` | Merge one or more incidents into a target incident | **required** `id`, `from`, `source_incident_ids` |
| `pagerduty_reassign_incident` | Reassign an incident to different users | **required** `id`, `from`, `assignee_ids`<br />optional `escalation_level` |
| `pagerduty_resolve_alert` | Resolve an alert within an incident | **required** `incident_id`, `id`, `from` |
| `pagerduty_resolve_incident` | Resolve an incident in PagerDuty | **required** `id`, `from`<br />optional `resolution` |
| `pagerduty_run_incident_workflow` | Run an incident workflow on a specific incident | **required** `id`, `incident_id` |
| `pagerduty_send_event` | Send an event to PagerDuty via the Events API v2. | **required** `routing_key`, `event_action`<br />optional `client`, `client_url`, `component`, `custom_details`, `dedup_key`, `event_class`, `group`, `severity`, `source`, `summary` |
| `pagerduty_snooze_incident` | Snooze an incident in PagerDuty for a specified duration | **required** `id`, `from`, `duration` |
| `pagerduty_update_incident` | Update an existing incident in PagerDuty (status, urgency, priority, etc.) | **required** `id`, `from`<br />optional `conference_bridge_number`, `conference_bridge_url`, `escalation_policy_id`, `priority_id`, `resolution`, `status`, `title`, `urgency` |
| `pagerduty_update_incident_priority` | Update the priority of an incident | **required** `id`, `from`, `priority_id` |

## ServiceNow

42 tools. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `servicenow-oauth-2-cc_add_attachment` | Upload a file as a native attachment on a ServiceNow record (e.g. an incident) by reference. The file appears in the record's Attachments — not in a comment or work note. | **required** `table_name`, `table_sys_id`, `file_name`, `source_url`<br />optional `mime_type` |
| `servicenow-oauth-2-cc_add_comment` | Add a comment or work note to any ServiceNow record | **required** `table`, `sys_id`, `comment`<br />optional `sysparm_display_value`, `sysparm_exclude_reference_link`, `sysparm_fields`, `work_notes` |
| `servicenow-oauth-2-cc_add_group_members` | Add one or more members to a ServiceNow group | **required** `group_id`, `members` |
| `servicenow-oauth-2-cc_assign_roles_to_user` | Assign one or more roles to a ServiceNow user | **required** `user_id`, `roles` |
| `servicenow-oauth-2-cc_create_article` | Create a new knowledge article in ServiceNow | **required** `title`, `text`, `short_description`, `knowledge_base`, `category`<br />optional `article_type`, `keywords`, `sysparm_display_value`, `sysparm_fields` |
| `servicenow-oauth-2-cc_create_category` | Create a new category in a ServiceNow knowledge base | **required** `title`, `knowledge_base`<br />optional `active`, `description`, `parent_category`, `parent_table`, `sysparm_display_value`, `sysparm_fields` |
| `servicenow-oauth-2-cc_create_group` | Create a new group in ServiceNow with optional member assignments | **required** `name`<br />optional `active`, `description`, `email`, `group_type`, `manager`, `members`, `parent`, `sysparm_display_value`, `sysparm_fields` |
| `servicenow-oauth-2-cc_create_knowledge_base` | Create a new knowledge base in ServiceNow | **required** `title`<br />optional `description`, `managers`, `owner`, `publish_workflow`, `retire_workflow`, `sysparm_display_value`, `sysparm_fields` |
| `servicenow-oauth-2-cc_create_record` | Create a new record in any ServiceNow table. The `data` argument is a JSON object whose keys are ServiceNow column names for the target table (e.g. for `incident`: `{"short_description": "...", "priority": "3", "caller_id": "<sys_id>"}`). | **required** `table`, `data`<br />optional `sysparm_display_value`, `sysparm_exclude_reference_link`, `sysparm_fields`, `sysparm_input_display_value`, `sysparm_suppress_auto_sys_field`, `sysparm_view` |
| `servicenow-oauth-2-cc_create_user` | Create a new user in ServiceNow with optional role assignments | **required** `user_name`, `first_name`, `last_name`, `email`<br />optional `active`, `department`, `location`, `manager`, `mobile_phone`, `password`, `phone`, `roles`, `sysparm_display_value`, `sysparm_fields`, `title` |
| `servicenow-oauth-2-cc_delete_group` | Delete a group from ServiceNow | **required** `sys_id` |
| `servicenow-oauth-2-cc_delete_record` | Delete a record from any ServiceNow table | **required** `table`, `sys_id` |
| `servicenow-oauth-2-cc_delete_user` | Delete a user from ServiceNow | **required** `sys_id` |
| `servicenow-oauth-2-cc_download_attachment_to_kindo_library` | Download a ServiceNow attachment's binary content into the Kindo file library so the LLM can read it. Required for analyzing images, screenshots, or document attachments — list_attachments returns only metadata, not binary content. | **required** `sys_id` |
| `servicenow-oauth-2-cc_get_group` | Get a specific ServiceNow group by sys_id or name | optional `name`, `sys_id`, `sysparm_display_value`, `sysparm_fields` |
| `servicenow-oauth-2-cc_get_knowledge_article` | Get a specific knowledge article by its sys_id | **required** `sys_id`<br />optional `sysparm_display_value`, `sysparm_fields` |
| `servicenow-oauth-2-cc_get_record` | Get a specific record from any ServiceNow table by sys_id | **required** `table`, `sys_id`<br />optional `sysparm_display_value`, `sysparm_exclude_reference_link`, `sysparm_fields`, `sysparm_query_no_domain`, `sysparm_view` |
| `servicenow-oauth-2-cc_get_record_by_field` | Get a ServiceNow record by looking up a specific field value (e.g., find an incident by its number) | **required** `table`, `field`, `value`<br />optional `sysparm_display_value`, `sysparm_exclude_reference_link`, `sysparm_fields`, `sysparm_query_no_domain`, `sysparm_view` |
| `servicenow-oauth-2-cc_get_user` | Get a specific ServiceNow user by sys_id or user_name | optional `sys_id`, `sysparm_display_value`, `sysparm_fields`, `user_name` |
| `servicenow-oauth-2-cc_list_attachments` | List attachments on a ServiceNow record. Filter by table_name and table_sys_id to scope to a single record (e.g. list all attachments on incident INC0105126). | optional `sysparm_fields`, `sysparm_limit`, `sysparm_offset`, `sysparm_query`, `table_name`, `table_sys_id` |
| `servicenow-oauth-2-cc_list_audit_logs` | Retrieve audit log entries for a specific ServiceNow record | **required** `record_id`, `table_name`<br />optional `fieldname`, `sysparm_display_value`, `sysparm_fields`, `sysparm_limit`, `sysparm_offset`, `sysparm_order_by`, `sysparm_query` |
| `servicenow-oauth-2-cc_list_categories` | List categories from a ServiceNow knowledge base | optional `active`, `knowledge_base`, `parent_category`, `query`, `sysparm_display_value`, `sysparm_fields`, `sysparm_limit`, `sysparm_offset`, `sysparm_order_by`, `sysparm_query` |
| `servicenow-oauth-2-cc_list_group_members` | List all members of a specific ServiceNow group | **required** `group_id`<br />optional `active`, `sysparm_display_value`, `sysparm_fields`, `sysparm_limit`, `sysparm_offset` |
| `servicenow-oauth-2-cc_list_groups` | List groups from ServiceNow with filtering by active status, type, and search query | optional `active`, `group_type`, `query`, `sysparm_display_value`, `sysparm_fields`, `sysparm_limit`, `sysparm_offset`, `sysparm_order_by`, `sysparm_query` |
| `servicenow-oauth-2-cc_list_knowledge_articles` | List knowledge articles from ServiceNow with filtering by category, knowledge base, workflow state, and text search | optional `kb_category`, `kb_knowledge_base`, `sysparm_display_value`, `sysparm_fields`, `sysparm_limit`, `sysparm_offset`, `sysparm_order_by`, `sysparm_query`, `text_search`, `workflow_state` |
| `servicenow-oauth-2-cc_list_knowledge_bases` | List knowledge bases from ServiceNow with optional filtering | optional `active`, `query`, `sysparm_display_value`, `sysparm_fields`, `sysparm_limit`, `sysparm_offset`, `sysparm_order_by`, `sysparm_query` |
| `servicenow-oauth-2-cc_list_records` | List records from any ServiceNow table with filtering and pagination | **required** `table`<br />optional `sysparm_display_value`, `sysparm_exclude_reference_link`, `sysparm_fields`, `sysparm_limit`, `sysparm_no_count`, `sysparm_offset`, `sysparm_query`, `sysparm_query_category`, `sysparm_query_no_domain`, `sysparm_suppress_pagination_header`, `sysparm_view` |
| `servicenow-oauth-2-cc_list_reports` | List available reports from ServiceNow with optional filtering | optional `active`, `category`, `report_type`, `sysparm_display_value`, `sysparm_fields`, `sysparm_limit`, `sysparm_offset`, `sysparm_query` |
| `servicenow-oauth-2-cc_list_tasks` | List tasks from ServiceNow with filtering by assignee, group, state, priority, and category | optional `assigned_to`, `assignment_group`, `category`, `priority`, `state`, `sysparm_display_value`, `sysparm_fields`, `sysparm_limit`, `sysparm_offset`, `sysparm_order_by`, `sysparm_query` |
| `servicenow-oauth-2-cc_list_user_groups` | List all groups that a specific user belongs to | **required** `user_id`<br />optional `active`, `sysparm_display_value`, `sysparm_fields`, `sysparm_limit`, `sysparm_offset` |
| `servicenow-oauth-2-cc_list_users` | List users from ServiceNow with filtering by name, email, department, active status, role, and group | optional `active`, `department`, `email`, `group`, `name_search`, `role`, `sysparm_display_value`, `sysparm_fields`, `sysparm_limit`, `sysparm_offset`, `sysparm_order_by`, `sysparm_query` |
| `servicenow-oauth-2-cc_publish_article` | Publish a knowledge article in ServiceNow by updating its workflow state | **required** `sys_id`<br />optional `sysparm_display_value`, `sysparm_fields`, `workflow_state`, `workflow_version` |
| `servicenow-oauth-2-cc_remove_group_members` | Remove one or more members from a ServiceNow group | **required** `group_id`, `members` |
| `servicenow-oauth-2-cc_remove_roles_from_user` | Remove one or more roles from a ServiceNow user | **required** `user_id`, `roles` |
| `servicenow-oauth-2-cc_replace_record` | Replace an existing record in any ServiceNow table (full replacement using PUT) | **required** `table`, `sys_id`, `data`<br />optional `sysparm_display_value`, `sysparm_exclude_reference_link`, `sysparm_fields`, `sysparm_input_display_value`, `sysparm_query_no_domain`, `sysparm_suppress_auto_sys_field`, `sysparm_view` |
| `servicenow-oauth-2-cc_search_records` | Search records in any ServiceNow table using an encoded query string | **required** `table`, `sysparm_query`<br />optional `sysparm_display_value`, `sysparm_exclude_reference_link`, `sysparm_fields`, `sysparm_limit`, `sysparm_no_count`, `sysparm_offset`, `sysparm_query_category`, `sysparm_query_no_domain`, `sysparm_suppress_pagination_header`, `sysparm_view` |
| `servicenow-oauth-2-cc_trigger_workflow` | Trigger a ServiceNow workflow via record creation/update or REST endpoint | **required** `method`<br />optional `record_data`, `record_id`, `table`, `trigger_data`, `trigger_url` |
| `servicenow-oauth-2-cc_update_article` | Update an existing knowledge article in ServiceNow. | **required** `sys_id`<br />optional `category`, `find_text`, `keywords`, `replace_all_occurrences`, `replace_text`, `short_description`, `sysparm_display_value`, `sysparm_fields`, `target_field`, `text` |
| `servicenow-oauth-2-cc_update_group` | Update an existing group in ServiceNow | **required** `sys_id`<br />optional `active`, `description`, `email`, `group_type`, `manager`, `name`, `parent`, `sysparm_display_value`, `sysparm_fields` |
| `servicenow-oauth-2-cc_update_record` | Partially update a record in any ServiceNow table. The `data` argument is a JSON object of ServiceNow column names → new values, e.g. `{"priority": "3", "state": "2"}`. Pass `data` as a top-level object — never as a string. | **required** `table`, `sys_id`, `data`<br />optional `sysparm_display_value`, `sysparm_exclude_reference_link`, `sysparm_fields`, `sysparm_input_display_value`, `sysparm_query_no_domain`, `sysparm_suppress_auto_sys_field`, `sysparm_view` |
| `servicenow-oauth-2-cc_update_task` | Update a task in ServiceNow (state, assignment, priority, description, work notes, etc.) | **required** `sys_id`<br />optional `assigned_to`, `assignment_group`, `comments`, `description`, `due_date`, `priority`, `short_description`, `state`, `sysparm_display_value`, `sysparm_fields`, `work_notes` |
| `servicenow-oauth-2-cc_update_user` | Update an existing user in ServiceNow | **required** `sys_id`<br />optional `active`, `department`, `email`, `first_name`, `last_name`, `location`, `manager`, `mobile_phone`, `password`, `phone`, `roles`, `sysparm_display_value`, `sysparm_fields`, `title`, `user_name` |

## Zendesk Support Suite

12 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `zendesk-mcp_add_ticket_comment` | Add a public reply or internal note to a Zendesk ticket. Provide exactly one of `body` or `html_body` (use `public=False` for an internal note). | **required** `ticket_id`<br />optional `author_id`, `body`, `html_body`, `public`, `status` |
| `zendesk-mcp_create_ticket` | Create a Zendesk ticket. | **required** `subject`<br />optional `additional_fields`, `assignee_id`, `comment_body`, `comment_html_body`, `comment_public`, `custom_fields`, `external_id`, `group_id`, `priority`, `requester_id`, `status`, `tags`, `ticket_type` |
| `zendesk-mcp_get_organization` | Get a single Zendesk organization by ID, including domain_names, tags, and organization fields. | **required** `organization_id` |
| `zendesk-mcp_get_ticket` | Get a single Zendesk ticket by ID. Use 'include' to side-load related entities (e.g. 'users,groups,organizations,comment_count'). | **required** `ticket_id`<br />optional `include` |
| `zendesk-mcp_get_user` | Get a single Zendesk user by ID. | **required** `user_id` |
| `zendesk-mcp_list_organizations` | List Zendesk organizations with cursor pagination. | optional `after`, `before`, `page_size` |
| `zendesk-mcp_list_ticket_comments` | List comments on a Zendesk ticket (full conversation history). Set `include_inline_images=True` to embed inline image references in HTML bodies. | **required** `ticket_id`<br />optional `after`, `before`, `include_inline_images`, `page_size` |
| `zendesk-mcp_list_tickets` | List Zendesk tickets with cursor pagination. Returns the raw Zendesk envelope containing 'tickets', 'meta' (cursors), and 'links'. | optional `after`, `before`, `page_size` |
| `zendesk-mcp_list_users` | List Zendesk users with cursor pagination. Optionally filter by role ('end-user', 'agent', 'admin') OR organization ID — not both. | optional `after`, `before`, `organization_id`, `page_size`, `role` |
| `zendesk-mcp_search_tickets` | Search Zendesk tickets using the Zendesk search query language. The 'type:ticket' pin is added automatically when the query does not start with a 'type:' pin. The per-ticket 'ticket_type:' field is not treated as a type pin. | **required** `query`<br />optional `page`, `per_page`, `sort_by`, `sort_order` |
| `zendesk-mcp_search_users` | Search Zendesk users by name, email, or external ID. The 'query' string can be a substring or full Zendesk search syntax. | **required** `query`<br />optional `page`, `per_page` |
| `zendesk-mcp_update_ticket` | Update a Zendesk ticket. Modify subject, status, priority, type, assignee/group/requester, tags (replace, add, or remove), external ID, and custom/additional fields. At least one field must be provided. | **required** `ticket_id`<br />optional `additional_fields`, `additional_tags`, `assignee_id`, `custom_fields`, `external_id`, `group_id`, `priority`, `remove_tags`, `requester_id`, `status`, `subject`, `tags`, `ticket_type` |

---

## Workplace

Source: https://docs.kindo.ai/reference/tool-catalog/workplace/

:::note[Beta]
The tool catalog is in beta and is a point-in-time snapshot of the integration inventory, so an entry can differ from what your organization sees in product.
:::

Messaging, mail, calendar, and document platforms an agent can read and post to. 16 integrations, 202 tools.

Tool names below are the fully qualified names an agent sees once the integration is connected. Where an integration offers more than one connection, the names shown use the primary connection's prefix; connecting through another variant prefixes its tools with that variant's own integration ID instead. See [Tool Catalog](/reference/tool-catalog/) for how tools are granted and named.

## Asana Gov

11 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `asana-gov_create_task` | Create a task. Provide a workspace gid, or one or more project gids (required if no workspace). Optionally place it in a section, assign it, and set a due date. | **required** `name`<br />optional `assignee`, `due_on`, `notes`, `projects`, `resource_subtype`, `section`, `workspace` |
| `asana-gov_get_current_user` | Get the authenticated user's identity (gid, name, email, workspaces). Use the returned gid, or the literal 'me', as an assignee value. | — |
| `asana-gov_get_project` | Get one project's details by gid, including its latest status update. | **required** `project_gid` |
| `asana-gov_get_task` | Get one task's full detail by gid: completion status, assignee, dates, the sections it belongs to, custom fields, and tags. | **required** `task_gid` |
| `asana-gov_list_project_sections` | List a project's sections (the board columns / status lanes). Use a section gid with list_tasks, create_task, or update_task to place a task in that column. | **required** `project_gid`<br />optional `limit`, `offset` |
| `asana-gov_list_projects` | List projects in a workspace. Filter by team or archived state. | **required** `workspace`<br />optional `archived`, `limit`, `offset`, `team` |
| `asana-gov_list_tasks` | List tasks in a project or a section (provide exactly one). Returns compact tasks with completion state; call get_task for full detail. | optional `completed_since`, `limit`, `offset`, `project`, `section` |
| `asana-gov_list_users` | List users in a workspace, with their email, to resolve assignees for create_task / update_task. | **required** `workspace`<br />optional `limit`, `offset` |
| `asana-gov_list_workspaces` | List the Asana Gov workspaces the authenticated user can access. Start here — a workspace gid is required by list_projects, list_users, and search_tasks. | optional `limit`, `offset` |
| `asana-gov_search_tasks` | Full-text search for tasks in a workspace, optionally filtered by assignee and completion state. | **required** `workspace`<br />optional `assignee`, `completed`, `limit`, `text` |
| `asana-gov_update_task` | Update a task: complete/uncomplete it (status), rename it, edit its notes, reassign it, reschedule its due date, and/or move it to a different section (board column). Provide at least one change. | **required** `task_gid`<br />optional `assignee`, `completed`, `due_on`, `name`, `notes`, `section` |

## Box

14 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `box_box_search` | Search for files/folders by query in Box | **required** `query`<br />optional `ancestorFolderIds`, `contentTypes`, `fileExtensions`, `limit`, `offset`, `trashContent`, `type` |
| `box_create_file_shared_link` | Create or update a shared link for a file with an access level and optional password/unshare date | **required** `fileId`, `access`<br />optional `canDownload`, `canEdit`, `canPreview`, `password`, `unsharedAt` |
| `box_create_folder` | Create a new subfolder in an existing parent folder | **required** `parentFolderId`, `name` |
| `box_create_folder_shared_link` | Create or update a shared link for a folder with an access level | **required** `folderId`, `access`<br />optional `canDownload`, `canPreview`, `password`, `unsharedAt` |
| `box_delete_file` | Delete a file by ID | **required** `fileId` |
| `box_delete_folder` | Delete a folder by ID. Optionally do a recursive delete | **required** `folderId`<br />optional `recursive` |
| `box_download_file_to_kindo_library` | Download a file from Box and save it to Kindo's file library. Returns the file content ID that can be used to reference the file. | **required** `fileId` |
| `box_get_file_info` | Get metadata for a file by ID | **required** `fileId` |
| `box_get_folder_info` | Retrieve metadata for a specific Box folder | **required** `folderId` |
| `box_get_recent_items` | Get a list of files and folders that were accessed by the current user within the last 90 days | optional `fields`, `limit`, `marker` |
| `box_list_folder_items` | List the items in a Box folder (files and subfolders) | **required** `folderId`<br />optional `limit`, `offset` |
| `box_remove_file_shared_link` | Remove any existing shared link from a file | **required** `fileId` |
| `box_remove_folder_shared_link` | Remove any existing shared link from a folder | **required** `folderId` |
| `box_upload_file` | Upload a new file to a folder in Box | **required** `folderId`, `fileName`, `fileContents` |

## Dropbox

10 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `dropbox_copy_file_or_folder` | Copy a file or folder in Dropbox | **required** `from_path`, `to_path` |
| `dropbox_create_folder` | Create a new folder in Dropbox | **required** `path` |
| `dropbox_delete_file_or_folder` | Delete a file or folder from Dropbox | **required** `path` |
| `dropbox_download_file_to_kindo_library` | Download a file from Dropbox to the kindo file library so that the contents can be read using the files_download_as_text tool. | **required** `path` |
| `dropbox_get_current_account` | Get the current user's Dropbox account info | — |
| `dropbox_get_space_usage` | Get the current user's Dropbox storage usage | — |
| `dropbox_list_folder_contents` | List the contents of a Dropbox folder | **required** `path`<br />optional `recursive` |
| `dropbox_move_file_or_folder` | Move or rename a file or folder in Dropbox | **required** `from_path`, `to_path` |
| `dropbox_search_files` | Search for files/folders in Dropbox | **required** `query`<br />optional `max_results`, `order_by`, `path` |
| `dropbox_upload_file` | Upload a file to Dropbox | **required** `path`, `contents_base64`<br />optional `mode` |

## Google Docs

4 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `google-docs_documents_batch_update` | Apply one or more updates to a Google Docs document. This is the primary method for editing documents programmatically — inserting text, formatting paragraphs, creating lists, inserting images, etc. | **required** `document_id`, `update_requests` |
| `google-docs_documents_create` | Create a new blank Google Docs document. Optionally provide a title for the document. Returns the newly created document with its ID. | optional `title` |
| `google-docs_documents_get` | Get the latest version of the specified Google Docs document. Returns the full document structure including body, headers, footers, and document properties. | **required** `document_id` |
| `google-docs_documents_list` | List all Google Docs documents accessible to the user. Returns basic metadata for each document including ID, name, creation/modification dates, and sharing information. Supports filtering by name, pagination, and custom sort orders. | optional `order_by`, `page_size`, `page_token`, `query` |

## Google Drive

26 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `google-drive_about_get` | Get information about the user's Google Drive account | — |
| `google-drive_channels_stop` | Stop watching resources through this channel | **required** `resource_id`, `channel_id` |
| `google-drive_comments_create` | Create a new comment on a file | **required** `file_id`, `content` |
| `google-drive_comments_delete` | Delete a comment | **required** `file_id`, `comment_id` |
| `google-drive_comments_get` | Get a comment by ID | **required** `file_id`, `comment_id` |
| `google-drive_comments_list` | List all comments on a file | **required** `file_id`<br />optional `page_size`, `page_token` |
| `google-drive_comments_update` | Update an existing comment | **required** `file_id`, `comment_id`, `content` |
| `google-drive_download_file_to_kindo_library` | Download a file from Google Drive to the Kindo file library for later retrieval. | **required** `file_id` |
| `google-drive_files_copy` | Copy an existing file | **required** `file_id`<br />optional `name`, `parents` |
| `google-drive_files_create` | Create (upload) a file from inline text content. The content is passed inline and is text-only, so it is subject to the ~10KB message-layer limit — larger or binary content is silently truncated. | **required** `name`<br />optional `content`, `mime_type`, `parents` |
| `google-drive_files_delete` | Delete a file by ID | **required** `file_id` |
| `google-drive_files_empty_trash` | Permanently delete all trashed files | — |
| `google-drive_files_export` | Export a Google Workspace document to a requested MIME type. Text results are returned as a decoded string; binary results are returned as a base64-encoded payload. | **required** `file_id`<br />optional `mime_type` |
| `google-drive_files_generate_ids` | Generate file IDs that can be used to create files | optional `count`, `space` |
| `google-drive_files_list` | List or search files. Trashed files are always excluded. | optional `fields`, `page_size`, `page_token`, `q`, `spaces` |
| `google-drive_files_update` | Update a file's metadata, or replace its content from inline text. The content is passed inline and is text-only, so it is subject to the ~10KB message-layer limit — larger or binary content is silently truncated. | **required** `file_id`<br />optional `content`, `mime_type`, `name` |
| `google-drive_files_watch` | Watch a file for changes | **required** `file_id`, `channel_id`, `address`, `resource_id`, `channel_type` |
| `google-drive_get_start_page_token` | Get a token for listing future changes to a user's Drive | optional `drive_id`, `supports_all_drives` |
| `google-drive_list_changes` | List changes for a user or shared drive | **required** `page_token`<br />optional `drive_id`, `page_size`, `restrict_to_my_drive`, `spaces` |
| `google-drive_permissions_create` | Create a permission for a file | **required** `file_id`, `role`, `permission_type`<br />optional `domain`, `email_address` |
| `google-drive_permissions_delete` | Delete a permission from a file | **required** `file_id`, `permission_id` |
| `google-drive_permissions_get` | Get a permission by ID | **required** `file_id`, `permission_id` |
| `google-drive_permissions_list` | List permissions of a file | **required** `file_id` |
| `google-drive_permissions_update` | Update a permission | **required** `file_id`, `permission_id`, `role`<br />optional `transfer_ownership` |
| `google-drive_upload_file` | Create or update a file's content by reference — for binary files or any content too large to pass inline. Pass `source_url`: a short-lived signed download URL minted by the `mint_upload_url` tool. | **required** `source_url`<br />optional `file_id`, `mime_type`, `name`, `parents` |
| `google-drive_watch_changes` | Watch changes to a user's drive | **required** `page_token`, `resource_id`, `channel_id`, `address`, `channel_type`<br />optional `page_size`, `restrict_to_my_drive`, `spaces` |

## Microsoft 365 Copilot (Application)

7 tools. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `m365-copilot-application_get_copilot_adoption_summary` | Tenant-wide Microsoft 365 Copilot adoption rollup: how many people are enabled for Copilot versus actually using it, broken out per surface (Teams, Word, Excel, Outlook, Copilot Chat, ...), plus total and average prompt volume. | optional `include_daily_trend`, `period` |
| `m365-copilot-application_get_copilot_interaction_thread` | Full text of one Microsoft 365 Copilot exchange, prompt and response together, with Adaptive Card responses unwrapped into readable text. | **required** `user_id`, `start_time`, `end_time`<br />optional `max_characters`, `request_id`, `session_id` |
| `m365-copilot-application_list_copilot_agents` | Inventory the agents, extensions and bots deployed in the tenant's Copilot catalog: what they are, who published them, which platform built them (including Copilot Studio), who can reach them, and which are blocked. | optional `blocked_only`, `element_type`, `host`, `limit`, `modified_since` |
| `m365-copilot-application_list_copilot_user_activity` | Per-user Microsoft 365 Copilot adoption: who is licensed, when they last used it, how many prompts they submitted, and on which surfaces. | optional `activity`, `limit`, `period`, `sort_by` |
| `m365-copilot-application_manage_copilot_license` | Grant or revoke a user's Microsoft 365 Copilot license — the on/off switch for one person's Copilot access, and the action that closes out the list_copilot_user_activity(activity='inactive') reclamation workflow. | **required** `user_id`, `action` |
| `m365-copilot-application_search_ai_audit_events` | Search Microsoft Purview audit for AI activity — the complement to search_copilot_interactions and the only place Copilot Studio agents and third-party 'shadow AI' apps show up. | **required** `start_time`, `end_time`<br />optional `activity`, `limit`, `user_principal_names` |
| `m365-copilot-application_search_copilot_interactions` | Search one user's Microsoft 365 Copilot prompts and responses — the DLP/compliance question, 'what did this person ask Copilot and what did it answer?'. | **required** `user_id`, `start_time`, `end_time`<br />optional `app_class`, `contains`, `limit`, `response_format` |

## Microsoft Excel

18 tools. Available as 2 connections: Microsoft Excel (OAuth 2.0), Microsoft Excel (GCC High) (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-excel_add_table_rows` | Add one or more rows of data to an existing table. Values is a 2D array where each inner list is one row matching the table's column order. | **required** `workbook_id`, `table`, `values`<br />optional `index`, `session_id` |
| `microsoft-excel_add_worksheet` | Add a new worksheet to an Excel workbook. Optionally specify a name. | **required** `workbook_id`<br />optional `name`, `session_id` |
| `microsoft-excel_clear_range` | Clear contents, formatting, or both from a cell range. Use applyTo to control what is cleared: 'All', 'Contents', or 'Formats'. | **required** `workbook_id`, `worksheet`, `address`<br />optional `apply_to`, `session_id` |
| `microsoft-excel_close_session` | Close an active workbook session to release resources. | **required** `workbook_id`, `session_id` |
| `microsoft-excel_create_session` | Create a workbook session for batch operations. Use persistent sessions for writes (changes saved to file) or non-persistent sessions for read-only analysis (temporary copy). Sessions expire after ~5 minutes of inactivity. | **required** `workbook_id`<br />optional `persist_changes` |
| `microsoft-excel_create_table` | Create a new table from a cell range on a worksheet. Specify the range address (e.g. 'A1:D10') and whether the first row contains headers. | **required** `workbook_id`, `worksheet`, `address`<br />optional `has_headers`, `session_id` |
| `microsoft-excel_create_workbook` | Create a new, empty Excel workbook (.xlsx) in OneDrive. Returns the drive item metadata including the item ID, which can be used as workbookId in all other Excel Online tools. | **required** `file_name`<br />optional `folder_id`, `folder_path` |
| `microsoft-excel_delete_worksheet` | Delete a worksheet from an Excel workbook by name or ID. | **required** `workbook_id`, `worksheet`<br />optional `session_id` |
| `microsoft-excel_get_range` | Read cell values, formulas, and number formats from a range in A1 notation. Example addresses: 'A1:C10', 'B2', 'A:A'. | **required** `workbook_id`, `worksheet`, `address`<br />optional `session_id` |
| `microsoft-excel_get_table_data` | Get rows and columns from a table by name or ID. Supports pagination with top (limit) and skip (offset) parameters. | **required** `workbook_id`, `table`<br />optional `session_id`, `skip`, `top` |
| `microsoft-excel_get_used_range` | Get the used range (bounding box of all non-empty cells) of a worksheet. Returns the address, values, formulas, and dimensions. | **required** `workbook_id`, `worksheet`<br />optional `session_id` |
| `microsoft-excel_get_worksheet` | Get details of a specific worksheet by name or ID, including its properties. | **required** `workbook_id`, `worksheet`<br />optional `session_id` |
| `microsoft-excel_list_drive_items` | List files and folders in a OneDrive folder. Defaults to the root of the user's drive. Use to browse for Excel workbooks. | optional `folder_id`, `folder_path`, `limit` |
| `microsoft-excel_list_named_items` | List all named ranges and constants defined in an Excel workbook. Returns the name, type, value, and visibility. | **required** `workbook_id`<br />optional `session_id` |
| `microsoft-excel_list_tables` | List all tables in an Excel workbook, or only tables on a specific worksheet. Returns table name, ID, column count, row count, and style. | **required** `workbook_id`<br />optional `session_id`, `worksheet` |
| `microsoft-excel_list_worksheets` | List all worksheets in an Excel workbook. Returns name, ID, position, and visibility for each sheet. | **required** `workbook_id`<br />optional `session_id` |
| `microsoft-excel_search_workbooks` | Search OneDrive for Excel workbooks by name. Finds .xlsx, .xlsm, and .xlsb files (Office Open XML formats). Returns file name, ID, path, size, and last modified date. Results may be fewer than limit since non-Excel files are filtered out. | **required** `query`<br />optional `limit` |
| `microsoft-excel_update_range` | Write values, formulas, and/or number formats to a cell range. Values and formulas are 2D arrays where each inner list is a row. Use null for cells to leave unchanged. | **required** `workbook_id`, `worksheet`, `address`<br />optional `formulas`, `number_format`, `session_id`, `values` |

## Microsoft Outlook

16 tools. Available as 2 connections: Microsoft Outlook (OAuth 2.0), Microsoft Outlook (GCC High) (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `outlook_create_event` | Create a new calendar event. Provide subject, start/end times, and optionally attendees, location, body, and Teams meeting link. | **required** `subject`, `start`, `end`<br />optional `attendees`, `body`, `body_type`, `calendar_id`, `importance`, `is_all_day`, `is_online_meeting`, `location`, `time_zone` |
| `outlook_delete_event` | Delete a calendar event by ID. | **required** `event_id` |
| `outlook_find_meeting_times` | Find available meeting times for a set of attendees within a time window. Returns suggested time slots when all (or a minimum percentage of) attendees are free. | **required** `attendees`, `start`, `end`<br />optional `is_organizer_optional`, `max_candidates`, `meeting_duration`, `minimum_attendee_percentage`, `time_zone` |
| `outlook_get_contact` | Get a single contact by ID with full details including all email addresses, phone numbers, addresses, and other information. | **required** `contact_id` |
| `outlook_get_event` | Get a single calendar event by ID with full details including attendees, location, body, and online meeting info. | **required** `event_id`<br />optional `time_zone` |
| `outlook_get_message` | Get a single message's full body and envelope by ID. | **required** `message_id`<br />optional `body_format`, `include_attachments_meta` |
| `outlook_get_schedule` | Get the free/busy availability for one or more users within a time window. Returns an availability view string where each character represents a time slot (0=free, 1=tentative, 2=busy, 3=out of office, 4=working elsewhere). | **required** `schedules`, `start`, `end`<br />optional `availability_view_interval`, `time_zone` |
| `outlook_list_calendars` | List the user's calendars. Returns calendar names, IDs, and colors. Useful for finding the right calendar ID for event operations. | optional `top` |
| `outlook_list_contacts` | List email addresses from the authenticated user's saved Outlook contacts (personal address book) via Microsoft Graph /me/contacts. | optional `search`, `top` |
| `outlook_list_emails` | List email addresses the authenticated user is most likely to send mail to (relevance-ranked recent collaborators) via Microsoft Graph /me/people. Lists PEOPLE/addresses, NOT inbox messages — to read or search mail, use list_messages. | optional `search`, `top` |
| `outlook_list_events` | List calendar events with optional date range filtering, search, and sorting. Use startDateTime and endDateTime to filter by date range. | optional `calendar_id`, `end_date_time`, `filter_query`, `orderby`, `search`, `select`, `skip`, `start_date_time`, `time_zone`, `top` |
| `outlook_list_mail_folders` | List the mail folders in the authenticated user's mailbox (id, display name, total/unread counts). Use a returned folder id — or a well-known name like 'inbox' or 'archive' — as the 'folder' argument of list_messages. | optional `include_child_folders`, `skip`, `top` |
| `outlook_list_messages` | List or search email messages in the authenticated user's mailbox (read-only). | optional `conversation_id`, `folder`, `from_address`, `has_attachments`, `importance`, `is_unread`, `received_after`, `received_before`, `search`, `skip`, `top` |
| `outlook_respond_to_event` | Respond to a meeting invitation by accepting, declining, or tentatively accepting. Optionally include a comment and choose whether to send a response to the organizer. | **required** `event_id`, `response`<br />optional `comment`, `send_response` |
| `outlook_send_email` | Send an email on behalf of the authenticated user via Microsoft Graph. Requires the Mail.Send scope. | **required** `to`, `subject`, `body`<br />optional `attachments`, `bcc`, `body_type`, `cc`, `importance`, `save_to_sent_items` |
| `outlook_update_event` | Update an existing calendar event. Can change subject, times, location, attendees, body, and other properties. When updating start/end times, the event's existing timezone is preserved if no new timezone is specified. | **required** `event_id`<br />optional `attendees`, `body`, `body_type`, `end`, `importance`, `is_all_day`, `location`, `start`, `subject`, `time_zone` |

## Microsoft Outlook Calendar

9 tools. Available as 2 connections: Microsoft Outlook Calendar (OAuth 2.0), Microsoft Outlook Calendar (GCC High) (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-outlook-calendar_create_event` | Create a new calendar event. Provide subject, start/end times, and optionally attendees, location, body, and Teams meeting link. | **required** `subject`, `start`, `end`<br />optional `attendees`, `body`, `body_type`, `calendar_id`, `importance`, `is_all_day`, `is_online_meeting`, `location`, `time_zone` |
| `microsoft-outlook-calendar_delete_event` | Delete a calendar event by ID. | **required** `event_id` |
| `microsoft-outlook-calendar_find_meeting_times` | Find available meeting times for a set of attendees within a time window. Returns suggested time slots when all (or a minimum percentage of) attendees are free. | **required** `attendees`, `start`, `end`<br />optional `is_organizer_optional`, `max_candidates`, `meeting_duration`, `minimum_attendee_percentage`, `time_zone` |
| `microsoft-outlook-calendar_get_event` | Get a single calendar event by ID with full details including attendees, location, body, and online meeting info. | **required** `event_id`<br />optional `time_zone` |
| `microsoft-outlook-calendar_get_schedule` | Get the free/busy availability for one or more users within a time window. Returns an availability view string where each character represents a time slot (0=free, 1=tentative, 2=busy, 3=out of office, 4=working elsewhere). | **required** `schedules`, `start`, `end`<br />optional `availability_view_interval`, `time_zone` |
| `microsoft-outlook-calendar_list_calendars` | List the user's calendars. Returns calendar names, IDs, and colors. Useful for finding the right calendar ID for event operations. | optional `top` |
| `microsoft-outlook-calendar_list_events` | List calendar events with optional date range filtering, search, and sorting. Use startDateTime and endDateTime to filter by date range. | optional `calendar_id`, `end_date_time`, `filter_query`, `orderby`, `search`, `select`, `skip`, `start_date_time`, `time_zone`, `top` |
| `microsoft-outlook-calendar_respond_to_event` | Respond to a meeting invitation by accepting, declining, or tentatively accepting. Optionally include a comment and choose whether to send a response to the organizer. | **required** `event_id`, `response`<br />optional `comment`, `send_response` |
| `microsoft-outlook-calendar_update_event` | Update an existing calendar event. Can change subject, times, location, attendees, body, and other properties. When updating start/end times, the event's existing timezone is preserved if no new timezone is specified. | **required** `event_id`<br />optional `attendees`, `body`, `body_type`, `end`, `importance`, `is_all_day`, `location`, `start`, `subject`, `time_zone` |

## Microsoft Teams

19 tools. Available as 2 connections: Microsoft Teams (OAuth 2.0), Microsoft Teams (GCC High) (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-teams_create_chat` | Create a one-on-one or group chat using user ids returned by search_users. | **required** `chat_type`, `member_ids`<br />optional `topic` |
| `microsoft-teams_download_file_to_kindo_library` | Download a Teams, SharePoint, or OneDrive file into the Kindo library so its contents can be read. Required for images — metadata alone cannot be viewed. | optional `drive_id`, `item_id`, `sharepoint_url` |
| `microsoft-teams_get_channel_messages` | — | **required** `team_id`<br />optional `channel_id`, `channel_name`, `cursor`, `limit`, `message_id` |
| `microsoft-teams_get_chat_messages` | — | **required** `chat_id`<br />optional `cursor`, `limit`, `message_id` |
| `microsoft-teams_get_current_user` | Get the Microsoft 365 user represented by this connection. | — |
| `microsoft-teams_get_drive_file` | Get file metadata by drive and item id. Returns a short-lived download_url; to read the file's contents, call download_file_to_kindo_library instead. | **required** `drive_id`, `item_id` |
| `microsoft-teams_get_meeting_transcript` | — | optional `join_web_url`, `meeting_id`, `transcript_format`, `transcript_id` |
| `microsoft-teams_get_sharepoint_file` | Get file metadata from a direct SharePoint or OneDrive file URL, not a sharing link. Returns a short-lived download_url; to read the file's contents, call download_file_to_kindo_library instead. | **required** `sharepoint_url` |
| `microsoft-teams_list_channel_files` | List files and folders in a Teams channel or a returned subfolder. When has_more is true, pass next_cursor back as cursor. | **required** `team_id`, `channel_id`<br />optional `cursor`, `folder_id`, `limit` |
| `microsoft-teams_list_channels` | List channels in a team before reading or sending channel messages. Graph returns every channel at once, so this tool does not paginate: if has_more is true, raise limit. | **required** `team_id`<br />optional `limit` |
| `microsoft-teams_list_chats` | List the connected user's direct and group chats before using chat message tools. When has_more is true, pass next_cursor back as cursor. | optional `cursor`, `limit` |
| `microsoft-teams_list_meeting_transcripts` | List available meeting transcripts. | optional `cursor`, `join_web_url`, `limit`, `meeting_id` |
| `microsoft-teams_list_teams` | List teams the connected user joined. Use a returned id for channel operations. Graph returns every joined team at once, so this tool does not paginate: if has_more is true, raise limit. | optional `limit` |
| `microsoft-teams_search_messages` | Search accessible Teams messages by keywords instead of browsing a known chat or channel. | **required** `query`<br />optional `limit`, `offset` |
| `microsoft-teams_search_users` | Find organization users before creating a chat. Matches the START of a display name or email, not any substring — pass 'ada', not 'lovelace', to find 'Ada Lovelace'. | **required** `query`<br />optional `cursor`, `limit` |
| `microsoft-teams_send_adaptive_card` | Send an Adaptive Card. card_payload is the card as a JSON string with type 'AdaptiveCard' and a version. Requires exactly one destination: team_id, optionally with channel_id or channel_name, or chat_id on its own. | **required** `card_payload`<br />optional `channel_id`, `channel_name`, `chat_id`, `team_id` |
| `microsoft-teams_send_channel_message` | Send plain text to a channel. Omit channel_id and channel_name to post to the team's primary channel (General, unless it was renamed). | **required** `team_id`, `content`<br />optional `channel_id`, `channel_name` |
| `microsoft-teams_send_chat_message` | Send plain text to a direct or group chat. | **required** `chat_id`, `content` |
| `microsoft-teams_send_html_message` | Send Teams-compatible HTML. Requires exactly one destination: team_id, optionally with channel_id or channel_name, or chat_id on its own. | **required** `content`<br />optional `channel_id`, `channel_name`, `chat_id`, `team_id` |

## monday.com

0 tools. Connect with OAuth 2.0.

## Notion

16 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `notion_append_blocks` | Add content blocks to a page or existing block. Blocks are appended at the end. | **required** `block_id`, `children` |
| `notion_create_comment` | Add a comment to a Notion page. The comment text is provided as plain text and will be converted to rich text. | **required** `page_id`, `text` |
| `notion_create_database` | Create a new inline database as a child of an existing page. Requires a parent page, title, and property schema definition. | **required** `parent`, `title`, `properties` |
| `notion_create_page` | Create a new page in a database or as a child of another page. Requires a parent and properties matching the parent schema. | **required** `parent`, `properties`<br />optional `children` |
| `notion_create_page_from_markdown` | Create a new Notion page from markdown text. Preferred over create_page for content-heavy pages. | **required** `parent`, `title`, `markdown`<br />optional `title_property` |
| `notion_delete_block` | Archive (soft-delete) a block by ID. | **required** `block_id` |
| `notion_get_database` | Get a database's schema (property definitions) by ID. Returns the database object with title, properties, and configuration. | **required** `database_id` |
| `notion_get_page` | Get a page's properties by ID. Returns the page object with all property values but not the page content (use get_page_content for that). | **required** `page_id` |
| `notion_get_page_as_markdown` | Get a Notion page's content as clean markdown text. Preferred over get_page_content for reading page content. | **required** `page_id` |
| `notion_get_page_content` | Get all content blocks of a page as raw Notion block JSON. For reading page content as text, prefer get_page_as_markdown instead. | **required** `page_id`<br />optional `page_size`, `start_cursor` |
| `notion_list_comments` | List comments on a Notion page. Returns comment objects with author, content, and timestamps. | **required** `page_id`<br />optional `page_size`, `start_cursor` |
| `notion_list_users` | List all users in the Notion workspace. Returns user objects with name, email, and avatar information. | optional `page_size`, `start_cursor` |
| `notion_query_database` | Query a database with optional filters, sorts, and pagination. Returns pages matching the criteria. | **required** `database_id`<br />optional `filter_query`, `page_size`, `sorts`, `start_cursor` |
| `notion_search` | Search across all pages and databases the integration has access to. Supports filtering by object type (page or database) and sorting by last_edited_time. | optional `filter_object_type`, `page_size`, `query`, `sort_direction`, `start_cursor` |
| `notion_update_block` | Update an existing block's content. Provide the block type key with the new content. | **required** `block_id`, `block_data` |
| `notion_update_page` | Update a page's properties or archive it. Only include the properties you want to change. Set archived=true to soft-delete. | **required** `page_id`<br />optional `archived`, `properties` |

## OneDrive

10 tools. Available as 2 connections: OneDrive (OAuth 2.0), OneDrive (GCC High) (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `one-drive_copy_item` | Copy a file or folder into another folder in the same drive. Graph runs the copy asynchronously and acknowledges immediately, so the copy may not exist yet when this returns; monitor_url reports its progress. | **required** `drive_id`, `item_id`, `parent_id`<br />optional `conflict_behavior`, `name` |
| `one-drive_create_folder` | Create a folder inside a parent folder. Pass parent_item_id='root' to create it at the top of the drive. | **required** `drive_id`, `parent_item_id`, `name`<br />optional `conflict_behavior` |
| `one-drive_create_sharing_link` | Create a sharing link for a file or folder. scope='anonymous' makes the link usable by anyone who has it — omit it to keep the link inside the organization. Returns the link URL. | **required** `drive_id`, `item_id`, `link_type`<br />optional `expiration_date_time`, `password`, `scope` |
| `one-drive_delete_item` | Delete a file or folder. OneDrive moves it to the recycle bin rather than erasing it. Deleting a folder deletes everything inside it. | **required** `drive_id`, `item_id` |
| `one-drive_download_file_to_kindo_library` | Download a OneDrive file into the Kindo library so its contents can be read. Required for images — a metadata listing alone cannot be viewed. Returns the file's metadata and the content id to read it by. | **required** `drive_id`, `item_id` |
| `one-drive_get_drive` | Get a single drive by id, including its quota and owner. | **required** `drive_id` |
| `one-drive_get_my_drive` | Get the connected user's default OneDrive, including its id, quota and owner. Call this first to obtain the drive_id the item tools need. | — |
| `one-drive_list_children` | List the files and folders inside a folder. Pass item_id='root' for the top of the drive. top is 1-250 (default 50); use skip to page. Prefer select to keep responses small when you only need a few fields. | **required** `drive_id`, `item_id`<br />optional `filter_query`, `orderby`, `select`, `skip`, `top` |
| `one-drive_list_drives` | List every drive the connected user can reach, including their personal OneDrive and any shared document libraries. | — |
| `one-drive_upload_file` | Upload a file to OneDrive by reference. Pass `source_url`: a short-lived signed download URL minted by the `mint_upload_url` tool. | **required** `drive_id`, `parent_item_id`, `file_name`, `source_url`<br />optional `conflict_behavior` |

## SharePoint Online (v2)

13 tools. Available as 3 connections: SharePoint Online (v2) (OAuth 2.0), SharePoint Online (Application) (OAuth 2.0 client credentials), SharePoint Online (GCC High) (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `sharepoint-online_create_folder` | Create a new folder in a SharePoint document library. Specify the parent folder by path or ID. | **required** `site_id`, `name`<br />optional `drive_id`, `parent_id`, `parent_path` |
| `sharepoint-online_create_list_item` | Create a new item in a SharePoint list. Provide column values as key-value pairs. | **required** `site_id`, `list_id`, `fields` |
| `sharepoint-online_get_drive_item` | Get metadata for a specific file or folder in a SharePoint drive. Provide either an item ID or a file path (e.g., 'Documents/report.pdf'). | **required** `site_id`<br />optional `drive_id`, `item_id`, `item_path` |
| `sharepoint-online_get_list` | Get details of a specific SharePoint list by ID or internal name. Use this to directly resolve a named list when you have a SharePoint URL containing '/Lists/&lt;name>/'. | **required** `site_id`, `list_id` |
| `sharepoint-online_get_site` | Get details of a specific SharePoint site by ID or path. Use a site ID directly, or a path like 'contoso.sharepoint.com:/sites/TeamSite'. | **required** `site_id` |
| `sharepoint-online_list_drive_items` | List files and folders in a SharePoint document library. Can list the root of a drive, or children of a specific folder by path or ID. | **required** `site_id`<br />optional `drive_id`, `folder_path`, `item_id`, `top` |
| `sharepoint-online_list_drives` | List all document libraries (drives) for a SharePoint site. Each drive contains files and folders. | **required** `site_id` |
| `sharepoint-online_list_list_items` | List items in a SharePoint list with optional field expansion and filtering. Use expandFields to include column values. Supports OData $filter expressions. | **required** `site_id`, `list_id`<br />optional `expand_fields`, `filter_query`, `top` |
| `sharepoint-online_list_lists` | List all SharePoint lists for a site. Returns list names, IDs, and metadata. | **required** `site_id`<br />optional `top` |
| `sharepoint-online_list_sites` | List all SharePoint sites the signed-in user can access. Returns each site's ID, name, and URL. Use this to discover sites when you have no specific keyword; use search_sites to filter by keyword. | optional `top` |
| `sharepoint-online_search_drive_items` | Search for files and folders within a SharePoint drive by keyword. Searches file names and content. | **required** `site_id`, `query`<br />optional `drive_id`, `top` |
| `sharepoint-online_search_sites` | Search for SharePoint sites by keyword. Returns matching sites with their IDs, names, and URLs. | **required** `query`<br />optional `top` |
| `sharepoint-online_upload_file` | Upload a file to a SharePoint document library. Pass `source_url`: a short-lived signed download URL minted by the `mint_upload_url` tool from a Kindo file (an attached or library file by content_id, or a file in the sandbox). | **required** `site_id`, `file_name`, `source_url`<br />optional `conflict_behavior`, `content_type`, `drive_id`, `folder_path` |

## Slack

8 tools. Connect with OAuth 2.0.

| Tool | Description | Arguments |
| --- | --- | --- |
| `slack_get_channel_history` | Retrieve message history for a Slack channel. The bot must be a member of the channel. Returns messages in reverse-chronological order. Paginate using the cursor from response_metadata.next_cursor. | **required** `channel`<br />optional `cursor`, `inclusive`, `latest`, `limit`, `oldest` |
| `slack_get_channel_members` | List user IDs of members in a Slack channel. Returns raw member IDs only; call get_user_info with each ID to resolve profile details. Paginate using the response cursor. | **required** `channel`<br />optional `cursor`, `limit` |
| `slack_get_user_info` | Get profile details for a Slack user. Accepts a user ID, email, username, or display name. For exact email lookups, lookup_user_by_email is more efficient (single API call, no pagination). | **required** `user` |
| `slack_list_channels` | List Slack public channels, private channels, and/or direct messages in the workspace. Archived channels are excluded by default; set exclude_archived=False to include them. Paginate via response_metadata.next_cursor. | **required** `types`<br />optional `cursor`, `exclude_archived`, `limit` |
| `slack_lookup_user_by_email` | Find a Slack user by exact email address. Prefer this over get_user_info when you have a known email -- it is a single API call with no pagination. Requires scope: users:read.email. | **required** `email` |
| `slack_open_conversation` | Open or resume a direct message or multi-person direct message. Requires either users (to open a new DM/mpim) or channel (to resume an existing one). Providing more than 8 users raises a validation error. | optional `channel`, `prevent_creation`, `return_im`, `users` |
| `slack_schedule_message` | Schedule a message to be sent at a specific future time to a Slack channel or direct message. post_at is a Unix timestamp in seconds; the message is not sent until that time. Requires scope: chat:write. | **required** `channel`, `text`, `post_at` |
| `slack_send_message` | Send a message immediately to a Slack channel or direct message. Supports plain text and Slack mrkdwn formatting. Use thread_ts to reply inside an existing thread. The bot must be a member of private channels. | **required** `channel`, `text`<br />optional `thread_ts` |

## Smartsheet

21 tools. Available as 2 connections: Smartsheet (OAuth 2.0), Smartsheet Gov (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `smartsheet_add_column` | Add a new column to a sheet. | **required** `sheet_id`, `title`<br />optional `column_format`, `column_type`, `description`, `hidden`, `index`, `locked`, `options`, `primary`, `symbol`, `validation`, `width` |
| `smartsheet_add_rows` | Add one or more rows to a sheet with cell values. When adding multiple rows, all rows MUST use the same row location attribute (e.g., all use `toBottom`, or all use `toTop`, or all use the same `parentId`). | **required** `sheet_id`, `rows` |
| `smartsheet_create_sheet` | Create a new sheet with specified columns. | **required** `name`, `columns` |
| `smartsheet_delete_rows` | Delete one or more rows from a sheet. | **required** `sheet_id`, `row_ids`<br />optional `ignore_rows_not_found` |
| `smartsheet_get_folder` | Get detailed information about a specific folder and its contents. | **required** `folder_id`<br />optional `include` |
| `smartsheet_get_folder_children` | Get children of a folder with pagination support and resource type filtering. | **required** `folder_id`<br />optional `children_resource_types`, `include`, `last_key`, `max_items` |
| `smartsheet_get_sheet` | Get detailed information about a specific sheet including rows, columns, and metadata. | **required** `sheet_id`<br />optional `column_ids`, `exclude`, `filter_id`, `if_version_after`, `include`, `row_ids`, `row_numbers` |
| `smartsheet_get_sheet_as_csv` | Export a sheet as CSV format for data analysis or import into other systems. | **required** `sheet_id` |
| `smartsheet_get_sheet_version` | Get the current version number of a sheet. | **required** `sheet_id` |
| `smartsheet_get_workspace` | Get a workspace by ID. Returns workspace metadata only (id, name, permalink, accessLevel) by default. | **required** `workspace_id`<br />optional `include`, `load_all` |
| `smartsheet_list_child_folders` | List all child folders within a parent folder. Returns folder IDs that may be needed for other folder operations. | **required** `folder_id`<br />optional `include_all`, `page`, `page_size` |
| `smartsheet_list_columns` | List all columns in a sheet. Returns column IDs required for add_rows, update_rows, and other cell operations. | **required** `sheet_id`<br />optional `include`, `level`, `page`, `page_size` |
| `smartsheet_list_home_folders` | List all folders in the user's home directory. Returns folder IDs required for other folder operations. | optional `include_all`, `page`, `page_size` |
| `smartsheet_list_rows` | Convenience wrapper that returns only row data from a sheet. Supports targeted retrieval by `row_ids` or `row_numbers` and pagination via `page_size`. Returned row IDs can be passed directly to `update_rows` / `delete_rows`. | **required** `sheet_id`<br />optional `exclude`, `include`, `page`, `page_size`, `row_ids`, `row_numbers` |
| `smartsheet_list_sheets` | List all sheets accessible to the user with optional filtering and pagination. Returns sheet IDs required by sheet-specific tools. | optional `include_owner_info`, `modified_since`, `page`, `page_size` |
| `smartsheet_list_workspace_folders` | List all folders within a specific workspace. Returns folder IDs that may be needed for other folder operations. | **required** `workspace_id`<br />optional `include_all`, `page`, `page_size` |
| `smartsheet_list_workspaces` | List all workspaces accessible to the user. Returns workspace IDs required for other workspace operations. | optional `include_all`, `page`, `page_size` |
| `smartsheet_search_all` | Search across all sheets, folders, workspaces, and other objects accessible to the user. Each result has `objectId` (numeric ID) and `objectType` (e.g. 'sheet', 'workspace', 'folder') — pass `objectId` into downstream tools. | **required** `query`<br />optional `location`, `modified_since`, `scopes` |
| `smartsheet_search_sheet` | Search within a specific sheet for rows, discussions, and summary fields. Returns row IDs that can be used for row operations. | **required** `sheet_id`, `query` |
| `smartsheet_update_rows` | Update one or more existing rows in a sheet. Each row MUST include the `id` field (the numeric row ID). Obtain row IDs via `list_rows` or `get_sheet`. | **required** `sheet_id`, `rows` |
| `smartsheet_update_sheet` | Update sheet properties like name, project settings, or user settings. | **required** `sheet_id`<br />optional `critical_path_enabled`, `display_summary_tasks`, `length_of_day`, `name`, `non_working_days`, `working_days` |

---

## Data and records

Source: https://docs.kindo.ai/reference/tool-catalog/data-records/

:::note[Beta]
The tool catalog is in beta and is a point-in-time snapshot of the integration inventory, so an entry can differ from what your organization sees in product.
:::

Data stores, warehouses, and records systems an agent can query and export from. 11 integrations, 185 tools.

Tool names below are the fully qualified names an agent sees once the integration is connected. Where an integration offers more than one connection, the names shown use the primary connection's prefix; connecting through another variant prefixes its tools with that variant's own integration ID instead. See [Tool Catalog](/reference/tool-catalog/) for how tools are granted and named.

## Cribl

34 tools. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `cribl_cancel_search_job` | Cancel a running Cribl Search job | **required** `job_id` |
| `cribl_commit_deploy` | Commit Cribl configuration changes with a message and optionally deploy to workers | **required** `message`<br />optional `deploy`, `worker_group` |
| `cribl_diagnose_worker_group` | Get a comprehensive diagnostic summary of a Cribl worker group including health, pipeline count, route count, source count, and destination count | **required** `worker_group_id` |
| `cribl_explain_data_flow` | Show the complete data flow topology for a worker group: all sources, routes with their pipeline and output references, and all destinations | optional `worker_group` |
| `cribl_get_collector` | Get one Cribl collector by exact ID with its full configuration | **required** `collector_id`<br />optional `worker_group` |
| `cribl_get_deployment_info` | Get Cribl deployment version, health status, and system information | optional `worker_group` |
| `cribl_get_git_status` | Get the git configuration and version control status for Cribl configuration management | optional `worker_group` |
| `cribl_get_input` | Get one Cribl source by exact ID or exact name when available | **required** `query`<br />optional `worker_group` |
| `cribl_get_lookup` | Get one Cribl lookup file by exact ID | **required** `lookup_id`<br />optional `worker_group` |
| `cribl_get_output` | Get one Cribl destination by exact ID or exact name when available | **required** `query`<br />optional `worker_group` |
| `cribl_get_pack` | Get one Cribl pack by exact ID | **required** `pack_id`<br />optional `worker_group` |
| `cribl_get_pipeline` | Get one Cribl pipeline by exact ID or exact description match | **required** `query`<br />optional `worker_group` |
| `cribl_get_route` | Get one Cribl route by exact route ID or route name | **required** `query`<br />optional `worker_group` |
| `cribl_get_search_job` | Get the status and optionally the results of a Cribl Search job by ID | **required** `job_id`<br />optional `include_results`, `limit`, `offset` |
| `cribl_get_system_health` | Get Cribl health status for the global system or a specific worker group | optional `worker_group` |
| `cribl_get_system_metrics` | Get Cribl internal system metrics including throughput, CPU, memory, and event processing stats | optional `worker_group` |
| `cribl_list_collectors` | List Cribl collectors (scheduled or ad-hoc data collection tasks) with optional filtering | optional `limit`, `query`, `worker_group` |
| `cribl_list_datasets` | List Cribl Search and Lake datasets available for querying | optional `limit`, `query` |
| `cribl_list_event_breakers` | List Cribl event breaker rule sets that define how raw data is split into discrete events | optional `limit`, `query`, `worker_group` |
| `cribl_list_global_variables` | List Cribl global variables (environment-level key-value pairs used across pipelines and routes) | optional `limit`, `query`, `worker_group` |
| `cribl_list_inputs` | List Cribl sources with optional worker group scoping and text filtering | optional `limit`, `query`, `worker_group` |
| `cribl_list_lookups` | List Cribl lookup files used for data enrichment in pipelines | optional `limit`, `query`, `worker_group` |
| `cribl_list_notification_targets` | List Cribl notification targets (webhooks, Slack endpoints, email) configured for system alerts | optional `limit`, `query` |
| `cribl_list_outputs` | List Cribl destinations with optional worker group scoping and text filtering | optional `limit`, `query`, `worker_group` |
| `cribl_list_packs` | List Cribl packs (bundles of pipelines, routes, and functions) with optional filtering | optional `limit`, `query`, `worker_group` |
| `cribl_list_pipelines` | List Cribl pipelines with optional worker group scoping and text filtering | optional `limit`, `query`, `worker_group` |
| `cribl_list_routes` | List individual Cribl routes from the routing table with optional worker group scoping | optional `limit`, `query`, `worker_group` |
| `cribl_list_search_jobs` | List Cribl Search jobs with their status, query, and timing metadata | optional `limit`, `query` |
| `cribl_list_worker_groups` | List Cribl Stream worker groups with optional text filtering | optional `limit`, `query` |
| `cribl_run_collector` | Trigger an ad-hoc run of a Cribl collector. Returns the job information for the triggered run | **required** `collector_id`<br />optional `worker_group` |
| `cribl_search_events` | Run a Cribl Search query, poll for completion, and return parsed event results with pagination metadata | **required** `query`<br />optional `dataset`, `earliest`, `latest`, `limit`, `max_wait_seconds`, `offset`, `sample_rate` |
| `cribl_toggle_input` | Enable or disable a Cribl source using a safe read-modify-write cycle. Concurrent edits to the same source between GET and PATCH may be lost | **required** `input_id`, `enabled`<br />optional `worker_group` |
| `cribl_toggle_output` | Enable or disable a Cribl destination using a safe read-modify-write cycle. Concurrent edits to the same destination between GET and PATCH may be lost | **required** `output_id`, `enabled`<br />optional `worker_group` |
| `cribl_toggle_route` | Enable or disable a Cribl route inside its routing table using a read-modify-write cycle: the table is re-fetched before PATCH, but the API replaces the whole table—concurrent edits to other routes in the same table can still be lost | **required** `route_id`, `enabled`<br />optional `worker_group` |

## Google BigQuery

7 tools. Credentials are supplied in the connection settings.

| Tool | Description | Arguments |
| --- | --- | --- |
| `google-bigquery_describe_table` | Get one table's column schema plus its row count, byte size, and partitioning. Free: reading table metadata scans no table bytes. Read this before writing SQL so column names and types are exact. | **required** `dataset_id`, `table_id`<br />optional `max_columns` |
| `google-bigquery_estimate_query_cost` | Dry-run a GoogleSQL query without executing it: reports whether it parses, how BigQuery classifies the statement, how many bytes it would scan, which tables it touches, and whether run_query would accept it. | **required** `sql` |
| `google-bigquery_get_query_results` | Page further into the results of a query that run_query already executed, addressed by its job_id. | **required** `job_id`<br />optional `limit`, `start_index` |
| `google-bigquery_list_datasets` | — | optional `limit` |
| `google-bigquery_list_tables` | — | **required** `dataset_id`<br />optional `limit` |
| `google-bigquery_preview_table_rows` | Read rows straight off a table, with no query involved. This costs nothing — BigQuery bills a query for every byte it scans, but reading stored rows is free. | **required** `dataset_id`, `table_id`<br />optional `columns`, `limit`, `start_index` |
| `google-bigquery_run_query` | Run a read-only GoogleSQL query. Every statement is dry-run first and executed only if BigQuery classifies it as a SELECT, so INSERT, UPDATE, DELETE, MERGE, CREATE and every other write is refused before anything runs. | **required** `sql`<br />optional `limit` |

## Microsoft eDiscovery

46 tools. Available as 4 connections: Microsoft eDiscovery (OAuth 2.0), Microsoft eDiscovery (Application) (OAuth 2.0 client credentials), Microsoft eDiscovery (GCC High) (OAuth 2.0), Microsoft eDiscovery (GCC High, Application) (OAuth 2.0 client credentials).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-ediscovery_activate_custodian` | Re-activate a previously released custodian in an eDiscovery case. | **required** `case_id`, `custodian_id` |
| `microsoft-ediscovery_add_case_member` | Add a user or role group as a member of an eDiscovery case. Provide recipientType and one of: memberId, smtpAddress (for users), or displayName (for role groups). | **required** `case_id`, `recipient_type`<br />optional `display_name`, `member_id`, `smtp_address` |
| `microsoft-ediscovery_add_to_review_set` | Add search results to a review set for further analysis and export. | **required** `case_id`, `review_set_id`, `search_id`<br />optional `additional_data_options` |
| `microsoft-ediscovery_apply_custodian_hold` | Place a legal hold on one or more custodians in an eDiscovery case. | **required** `case_id`, `ids` |
| `microsoft-ediscovery_apply_noncustodial_hold` | Place a legal hold on a non-custodial data source in an eDiscovery case. | **required** `case_id`, `noncustodial_data_source_id` |
| `microsoft-ediscovery_close_case` | Close an active eDiscovery case. | **required** `case_id` |
| `microsoft-ediscovery_create_case` | Create a new eDiscovery case with a display name, optional description, and external ID. | **required** `display_name`<br />optional `description`, `external_id` |
| `microsoft-ediscovery_create_custodian` | Add a custodian to an eDiscovery case by their email address. | **required** `case_id`, `email` |
| `microsoft-ediscovery_create_hold_site_source` | Add a SharePoint site to a legal hold policy by its URL. | **required** `case_id`, `hold_id`, `site_web_url` |
| `microsoft-ediscovery_create_hold_user_source` | Add a user's mailbox to a legal hold policy by email address. This automatically also covers the user's own OneDrive site, so no separate call is needed for it. | **required** `case_id`, `hold_id`, `email` |
| `microsoft-ediscovery_create_legal_hold` | Create a legal hold policy in an eDiscovery case with an optional KQL content query. | **required** `case_id`, `display_name`<br />optional `content_query`, `description`, `is_enabled` |
| `microsoft-ediscovery_create_noncustodial_data_source` | Add a non-custodial data source (SharePoint site or user mailbox) to an eDiscovery case. | **required** `case_id`, `data_source_type`<br />optional `email`, `site_web_url` |
| `microsoft-ediscovery_create_review_set` | Create a new review set in an eDiscovery case. | **required** `case_id`, `display_name`<br />optional `description` |
| `microsoft-ediscovery_create_search` | Create a new eDiscovery search with a KQL content query and data source scopes. | **required** `case_id`, `display_name`<br />optional `content_query`, `data_source_scopes`, `description` |
| `microsoft-ediscovery_delete_case` | Delete an eDiscovery case by its ID. | **required** `case_id` |
| `microsoft-ediscovery_delete_hold_site_source` | Remove a SharePoint site source from a legal hold policy. | **required** `case_id`, `hold_id`, `site_source_id` |
| `microsoft-ediscovery_delete_hold_user_source` | Remove a user source from a legal hold policy. | **required** `case_id`, `hold_id`, `user_source_id` |
| `microsoft-ediscovery_delete_legal_hold` | Delete a legal hold policy from an eDiscovery case. | **required** `case_id`, `hold_id` |
| `microsoft-ediscovery_estimate_search_statistics` | Run an estimate statistics operation on data matched by an eDiscovery search. Returns estimated item count and size. | **required** `case_id`, `search_id` |
| `microsoft-ediscovery_export_review_set` | Export data from a review set in an eDiscovery case. | **required** `case_id`, `review_set_id`, `output_name`<br />optional `description`, `export_options`, `export_structure` |
| `microsoft-ediscovery_export_search_result` | Export results from an estimated eDiscovery search. Requires additionalOptions, exportCriteria, and exportFormat. | **required** `case_id`, `search_id`, `additional_options`, `export_criteria`, `export_format`<br />optional `description`, `display_name`, `export_location` |
| `microsoft-ediscovery_get_case` | Get details of a specific eDiscovery case by its ID. | **required** `case_id` |
| `microsoft-ediscovery_get_custodian` | Get details of a specific custodian in an eDiscovery case, including hold status and email. | **required** `case_id`, `custodian_id` |
| `microsoft-ediscovery_get_legal_hold` | Get details of a specific legal hold policy in an eDiscovery case. | **required** `case_id`, `hold_id` |
| `microsoft-ediscovery_get_noncustodial_data_source` | Get details of a specific non-custodial data source in an eDiscovery case. | **required** `case_id`, `noncustodial_data_source_id` |
| `microsoft-ediscovery_get_search` | Get details of a specific eDiscovery search. | **required** `case_id`, `search_id` |
| `microsoft-ediscovery_list_case_members` | List members (users and role groups) of an eDiscovery case. | **required** `case_id`<br />optional `filter_query`, `skip`, `top` |
| `microsoft-ediscovery_list_case_operations` | List long-running operations in an eDiscovery case (exports, holds, index operations, etc.). | **required** `case_id`<br />optional `filter_query`, `skip`, `top` |
| `microsoft-ediscovery_list_cases` | List all eDiscovery cases. Supports OData filtering, pagination, and ordering. | optional `filter_query`, `orderby`, `skip`, `top` |
| `microsoft-ediscovery_list_custodians` | List custodians in an eDiscovery case. Custodians are people whose data is under investigation. | **required** `case_id`<br />optional `filter_query`, `skip`, `top` |
| `microsoft-ediscovery_list_hold_site_sources` | List SharePoint site sources associated with a legal hold policy. | **required** `case_id`, `hold_id`<br />optional `filter_query`, `skip`, `top` |
| `microsoft-ediscovery_list_hold_user_sources` | List user (mailbox) sources associated with a legal hold policy. | **required** `case_id`, `hold_id`<br />optional `filter_query`, `skip`, `top` |
| `microsoft-ediscovery_list_legal_holds` | List legal hold policies in an eDiscovery case. | **required** `case_id`<br />optional `filter_query`, `skip`, `top` |
| `microsoft-ediscovery_list_noncustodial_data_sources` | List non-custodial data sources (shared mailboxes, team sites) in an eDiscovery case. | **required** `case_id`<br />optional `filter_query`, `skip`, `top` |
| `microsoft-ediscovery_list_review_sets` | List review sets in an eDiscovery case. | **required** `case_id`<br />optional `filter_query`, `skip`, `top` |
| `microsoft-ediscovery_list_searches` | List searches in an eDiscovery case. | **required** `case_id`<br />optional `filter_query`, `skip`, `top` |
| `microsoft-ediscovery_release_custodian` | Release a custodian from an eDiscovery case. The custodian's data sources are no longer actively managed. | **required** `case_id`, `custodian_id` |
| `microsoft-ediscovery_release_noncustodial_data_source` | Release a non-custodial data source from an eDiscovery case. | **required** `case_id`, `noncustodial_data_source_id` |
| `microsoft-ediscovery_remove_case_member` | Remove a member (user or role group) from an eDiscovery case. | **required** `case_id`, `member_id` |
| `microsoft-ediscovery_remove_custodian_hold` | Remove a legal hold from one or more custodians in an eDiscovery case. | **required** `case_id`, `ids` |
| `microsoft-ediscovery_remove_noncustodial_hold` | Remove a legal hold from a non-custodial data source in an eDiscovery case. | **required** `case_id`, `noncustodial_data_source_id` |
| `microsoft-ediscovery_reopen_case` | Reopen a closed eDiscovery case. | **required** `case_id` |
| `microsoft-ediscovery_retry_hold_policy` | Retry a legal hold policy to restamp all mailboxes and sites. Use when the hold status shows errors. | **required** `case_id`, `hold_id` |
| `microsoft-ediscovery_update_case` | Update properties of an eDiscovery case (display name, description, external ID). | **required** `case_id`<br />optional `description`, `display_name`, `external_id` |
| `microsoft-ediscovery_update_legal_hold` | Update properties of a legal hold policy (description, content query). | **required** `case_id`, `hold_id`<br />optional `content_query`, `description` |
| `microsoft-ediscovery_update_noncustodial_index` | Trigger a re-index operation on a non-custodial data source to make it searchable. | **required** `case_id`, `noncustodial_data_source_id` |

## Microsoft Fabric

3 tools. Connect with OAuth 2.0 client credentials.

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-fabric_get_schema` | Get the column schema for a specific table in the Microsoft Fabric Lakehouse. Returns detailed information about each column including data types, nullability, and defaults. | **required** `tableName`<br />optional `includeColumnDefaults`, `schemaName` |
| `microsoft-fabric_get_tables` | List available tables in the Microsoft Fabric Lakehouse. Returns a list of table names with optional metadata like row counts and schema information. | optional `includeRowCounts`, `includeSystemTables`, `schemaName` |
| `microsoft-fabric_run_query` | Execute a SQL query against the Microsoft Fabric Lakehouse. Supports T-SQL syntax as used in Microsoft SQL Server and Azure Synapse. Resulting privileges depend entirely on the supplied service principal. | **required** `sqlQuery`<br />optional `includeExecutionStats`, `maxRows`, `parameters`, `queryTimeout` |

## Microsoft Purview Compliance

14 tools. Available as 4 connections: Microsoft Purview Compliance (OAuth 2.0), Microsoft Purview Compliance (Application) (OAuth 2.0 client credentials), Microsoft Purview Compliance (GCC High) (OAuth 2.0), Microsoft Purview Compliance (GCC High, Application) (OAuth 2.0 client credentials).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-purview-compliance_assign_sensitivity_label` | Assign a sensitivity label to a file in OneDrive or SharePoint. | **required** `drive_id`, `item_id`, `sensitivity_label_id`<br />optional `assignment_method`, `justification_text` |
| `microsoft-purview-compliance_compute_protection_scopes` | Determine which Microsoft Purview DLP policies apply and what activities they cover. | optional `activities`, `pivot_on` |
| `microsoft-purview-compliance_create_audit_log_query` | Create an audit log search query with date range and optional filters for record types, operations, users, and services. Use get_audit_log_query to check status, then list_audit_log_records to retrieve results once the query succeeds. | **required** `display_name`, `filter_start_date_time`, `filter_end_date_time`<br />optional `administrative_unit_id_filters`, `ip_address_filters`, `keyword_filter`, `object_id_filters`, `operation_filters`, `record_type_filters`, `service_filter`, `user_principal_name_filters` |
| `microsoft-purview-compliance_get_alert` | Get a single security alert by ID, including evidence artifacts and MITRE ATT&CK techniques | **required** `alert_id` |
| `microsoft-purview-compliance_get_audit_log_query` | Get the status and details of an audit log query by ID. Check the status field to know when results are ready (succeeded). Uses the beta Graph endpoint. | **required** `query_id` |
| `microsoft-purview-compliance_get_incident` | Get a single security incident by ID, optionally expanding related alerts | **required** `incident_id`<br />optional `expand_alerts` |
| `microsoft-purview-compliance_list_alerts` | List security alerts from Microsoft Purview DLP and other compliance services. Filter by severity, status, service source (e.g., dataLossPrevention), classification, assignee, and date range. top is 1-250 (default 50). | optional `assigned_to`, `classification`, `created_after`, `created_before`, `determination`, `expand`, `filter_query`, `last_updated_after`, `last_updated_before`, `orderby`, `select`, `service_source`, `severity`, `skip`, `status`, `top` |
| `microsoft-purview-compliance_list_audit_log_records` | List audit log records from a completed query. The query must be in 'succeeded' status before records can be retrieved. top is 1-250 (default 50). Uses the beta Graph endpoint. | **required** `query_id`<br />optional `expand`, `filter_query`, `orderby`, `select`, `skip`, `top` |
| `microsoft-purview-compliance_list_incidents` | List security incidents from Microsoft Purview DLP and other compliance services. Filter by severity, status, classification, assignee, and date range. top is 1-250 (default 50). | optional `assigned_to`, `classification`, `created_after`, `created_before`, `determination`, `expand`, `filter_query`, `last_updated_after`, `last_updated_before`, `orderby`, `select`, `severity`, `skip`, `status`, `top` |
| `microsoft-purview-compliance_list_sensitivity_labels` | List Microsoft Purview sensitivity labels, including label IDs, names, descriptions, and protection settings. | optional `expand`, `filter_query`, `select`, `skip`, `top` |
| `microsoft-purview-compliance_process_content` | Required: content_text and activity_type (one of uploadText, downloadText, uploadFile, downloadFile). | **required** `content_text`, `activity_type`<br />optional `correlation_id`, `name`, `target_user_id` |
| `microsoft-purview-compliance_run_hunting_query` | Execute a KQL query against Microsoft 365 Defender raw data for compliance threat hunting (up to 30 days, max 100K rows) | **required** `query`<br />optional `timespan` |
| `microsoft-purview-compliance_update_alert` | Requires at least one of: status, assigned_to, classification, determination, custom_details. Update a security alert. | **required** `alert_id`<br />optional `assigned_to`, `classification`, `custom_details`, `determination`, `status` |
| `microsoft-purview-compliance_update_incident` | Requires at least one of: status, severity, assigned_to, classification, determination, custom_tags, display_name, description, summary, resolving_comment. Update a security incident. | **required** `incident_id`<br />optional `assigned_to`, `classification`, `custom_tags`, `description`, `determination`, `display_name`, `resolving_comment`, `severity`, `status`, `summary` |

## Microsoft Purview Data Governance

34 tools. Available as 2 connections: Microsoft Purview Data Governance (OAuth 2.0), Microsoft Purview Data Governance (Government) (OAuth 2.0).

| Tool | Description | Arguments |
| --- | --- | --- |
| `microsoft-purview_add_entity_classifications` | Add one or more classifications (labels/tags) to a Microsoft Purview entity. Each classification requires a typeName. | **required** `guid`, `classifications` |
| `microsoft-purview_assign_glossary_term` | Assign a Microsoft Purview glossary term to one or more entities (data assets) | **required** `term_id`, `entity_guids` |
| `microsoft-purview_create_glossary_term` | Create a new term in a Microsoft Purview business glossary with name, description, and optional status | **required** `name`<br />optional `anchor`, `long_description`, `qualified_name`, `short_description`, `status` |
| `microsoft-purview_create_or_update_collection` | Create or update a Microsoft Purview collection for organizing data assets | **required** `collection_name`<br />optional `description`, `friendly_name`, `parent_collection` |
| `microsoft-purview_create_or_update_data_source` | Register or update a data source in Microsoft Purview for scanning. Provide the kind (e.g. AzureSqlDatabase) and connection properties. | **required** `data_source_name`, `kind`, `properties`<br />optional `collection` |
| `microsoft-purview_create_or_update_entity` | Create or update a Microsoft Purview entity (data asset). Provide the entity object with typeName, attributes (including qualifiedName and name), and optional classifications. | **required** `entity`<br />optional `referred_entities` |
| `microsoft-purview_create_or_update_scan` | Create or update a scan definition for a Microsoft Purview data source. Provide the kind and scan properties. | **required** `data_source_name`, `scan_name`, `kind`, `properties` |
| `microsoft-purview_create_relationship` | Create a relationship between two Microsoft Purview entities. Provide typeName and end1/end2 with entity GUIDs. | **required** `relationship` |
| `microsoft-purview_delete_collection` | Delete a Microsoft Purview collection by its name. The collection must be empty. | **required** `collection_name` |
| `microsoft-purview_delete_entity` | Delete a Microsoft Purview entity (data asset) by its GUID. This permanently removes the entity from the catalog. | **required** `guid` |
| `microsoft-purview_delete_relationship` | Delete a relationship between Microsoft Purview entities by its GUID | **required** `guid` |
| `microsoft-purview_get_classification_def` | Get a Microsoft Purview classification (label) type definition by name (e.g. 'MICROSOFT.PERSONAL.NAME') | **required** `name` |
| `microsoft-purview_get_collection` | Get a Microsoft Purview collection by its name, including its hierarchy path and description | **required** `collection_name` |
| `microsoft-purview_get_data_source` | Get a registered Microsoft Purview data source by name | **required** `data_source_name` |
| `microsoft-purview_get_entity` | Get complete definition of a Microsoft Purview entity (data asset) by its GUID, including attributes, classifications, and relationships | **required** `guid`<br />optional `ignore_relationships`, `min_ext_info` |
| `microsoft-purview_get_entity_by_qualified_name` | Get a Microsoft Purview entity by its type name and fully qualified name (e.g. type='azure_sql_table', qualifiedName='mssql://server/db/schema/table') | **required** `type_name`, `qualified_name`<br />optional `ignore_relationships`, `min_ext_info` |
| `microsoft-purview_get_entity_classifications` | Get all classifications (labels/tags) assigned to a Microsoft Purview entity | **required** `guid` |
| `microsoft-purview_get_glossary` | Get a Microsoft Purview business glossary by its GUID, including its terms and categories | **required** `glossary_id` |
| `microsoft-purview_get_glossary_term` | Get a Microsoft Purview glossary term by its GUID, including its definition, status, and assigned entities | **required** `term_id` |
| `microsoft-purview_get_lineage` | Get data lineage graph for a Microsoft Purview entity. Shows upstream (INPUT), downstream (OUTPUT), or both directions of data flow. | **required** `guid`<br />optional `depth`, `direction` |
| `microsoft-purview_get_relationship` | Get a Microsoft Purview entity relationship by its GUID | **required** `guid`<br />optional `extended_info` |
| `microsoft-purview_get_scan` | Get a scan definition by name for a Microsoft Purview data source | **required** `data_source_name`, `scan_name` |
| `microsoft-purview_list_child_collection_names` | List the names of child collections under a parent collection in Microsoft Purview | **required** `collection_name`<br />optional `skip_token` |
| `microsoft-purview_list_collections` | List all collections in the Microsoft Purview account. Collections organize data assets into a hierarchy. | optional `skip_token` |
| `microsoft-purview_list_data_sources` | List all registered data sources in Microsoft Purview. Data sources represent connected data stores that can be scanned. | — |
| `microsoft-purview_list_glossaries` | List all business glossaries in Microsoft Purview with optional pagination | optional `limit`, `offset`, `sort` |
| `microsoft-purview_list_glossary_terms` | List terms in a Microsoft Purview business glossary with optional pagination | **required** `glossary_id`<br />optional `limit`, `offset`, `sort` |
| `microsoft-purview_list_scan_history` | List the run history for a Microsoft Purview scan, showing status, start time, and scan results | **required** `data_source_name`, `scan_name` |
| `microsoft-purview_list_scans` | List all scan definitions for a Microsoft Purview data source | **required** `data_source_name` |
| `microsoft-purview_list_type_headers` | List Microsoft Purview type definition headers (names, categories, GUIDs) with optional filtering by type category | optional `include_term_template`, `type_category` |
| `microsoft-purview_run_scan` | Trigger a scan run for a Microsoft Purview data source. Optionally specify scan level (Full or Incremental). | **required** `data_source_name`, `scan_name`<br />optional `scan_level` |
| `microsoft-purview_search_entities` | Search Microsoft Purview data catalog for entities (data assets) using keywords, filters, and facets. Returns matching entities with relevance scoring. | optional `continuation_token`, `facets`, `filter_query`, `keywords`, `limit`, `offset` |
| `microsoft-purview_update_glossary_term` | Update an existing Microsoft Purview glossary term's name, description, or status | **required** `term_id`<br />optional `long_description`, `name`, `short_description`, `status` |
| `microsoft-purview_update_relationship` | Update an existing relationship between Microsoft Purview entities | **required** `relationship` |

## MongoDB

17 tools. Credentials are supplied in the connection settings.

| Tool | Description | Arguments |
| --- | --- | --- |
| `mongodb_aggregate` | Run a MongoDB aggregation pipeline on a collection. Supports all standard stages ($match, $group, $sort, $project, $lookup, etc.). $out and $merge stages are blocked. Returns up to 200 results | **required** `database`, `collection`, `pipeline`<br />optional `limit` |
| `mongodb_count_documents` | Count the number of documents in a collection matching an optional filter | **required** `database`, `collection`<br />optional `filter_query` |
| `mongodb_create_collection` | Create a new collection in a database, optionally with a JSON Schema validator for document validation. If the database does not exist, it will be created automatically | **required** `database`, `collection`<br />optional `validator` |
| `mongodb_create_index` | Create an index on a collection. Supports single-field, compound, unique, sparse, and TTL indexes. Returns the created index name | **required** `database`, `collection`, `keys`<br />optional `expire_after_seconds`, `name`, `sparse`, `unique` |
| `mongodb_delete_documents` | Delete documents matching a filter. Returns the count of deleted documents | **required** `database`, `collection`, `filter_query` |
| `mongodb_distinct_values` | Get all distinct values for a specific field in a collection, optionally filtered | **required** `database`, `collection`, `field`<br />optional `filter_query` |
| `mongodb_drop_index` | Drop an index from a collection by name. Use list_indexes to find index names | **required** `database`, `collection`, `index_name` |
| `mongodb_explain` | Return the execution plan for a query, showing whether indexes are used, how many documents are scanned, and execution statistics. Useful for debugging slow queries and optimizing performance | **required** `database`, `collection`<br />optional `filter_query`, `method`, `pipeline`, `projection`, `sort`, `verbosity` |
| `mongodb_find_documents` | Query documents in a collection with optional filter, projection, sort, skip, and limit. Returns up to 100 documents. Operators $where, $function, and $accumulator are blocked for security | **required** `database`, `collection`<br />optional `filter_query`, `limit`, `projection`, `skip`, `sort` |
| `mongodb_get_collection_schema` | Infer the schema of a collection by sampling documents. Returns field names and their observed types. Note: schema is inferred from a sample and may not represent the full collection | **required** `database`, `collection`<br />optional `sample_size` |
| `mongodb_get_collection_stats` | Get statistics for a collection including document count, size, index count, and storage metrics | **required** `database`, `collection` |
| `mongodb_get_database_stats` | Get statistics for a database including collection count, data size, storage size, and index count | **required** `database` |
| `mongodb_insert_documents` | Insert one or more documents into a collection. Returns the count and IDs of inserted documents | **required** `database`, `collection`, `documents` |
| `mongodb_list_collections` | List all collections in a database with their types and options | **required** `database` |
| `mongodb_list_databases` | List all databases on the MongoDB server with name, size, and empty status | — |
| `mongodb_list_indexes` | List all indexes on a collection with their keys, options, and names | **required** `database`, `collection` |
| `mongodb_update_documents` | Update documents matching a filter using MongoDB update operators ($set, $unset, $inc, $push, $pull, etc.). Returns matched and modified counts | **required** `database`, `collection`, `filter_query`, `update`<br />optional `upsert` |

## Neo4j Aura

4 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `neo4j_create_graph` | Create a new campaign with IAM data and populate the graph database. | **required** `csvFiles` |
| `neo4j_get_graph_schema` | Get the schema of the Neo4j graph database. | — |
| `neo4j_list_campaigns` | List all campaigns in the Neo4j database. | — |
| `neo4j_query_graph` | Execute a Cypher query against the Neo4j graph database. IMPORTANT: Use the get_graph_schema tool first to understand the database structure before writing queries. | **required** `cypherQuery`<br />optional `parameters` |

## Oracle Database

7 tools. Credentials are supplied in the connection settings.

| Tool | Description | Arguments |
| --- | --- | --- |
| `oracle-database_describe_table` | Get detailed structure of a table or view: column names, data types, nullability, defaults, and column comments. Essential for understanding table structure before writing queries. | **required** `schema`, `table` |
| `oracle-database_execute_query` | Execute a read-only SQL SELECT query against the Oracle Database. Only SELECT and WITH (CTE) statements are allowed. Use bind parameters (:param_name) to prevent SQL injection. Results are limited to max_rows (default 200). | **required** `sql`<br />optional `bind_params`, `max_rows` |
| `oracle-database_explain_plan` | Get the execution plan for a SQL SELECT query. Useful for understanding query performance, identifying full table scans, and optimizing queries before execution. Only SELECT and WITH (CTE) statements are allowed. | **required** `sql`<br />optional `bind_params` |
| `oracle-database_get_table_constraints` | Get all constraints for a table: primary keys, foreign keys, unique constraints, and check constraints. Includes referenced table information for foreign keys. | **required** `schema`, `table` |
| `oracle-database_get_table_indexes` | Get all indexes for a table: index name, type (NORMAL, BITMAP, etc.), uniqueness, status, and indexed columns. Useful for understanding query performance characteristics. | **required** `schema`, `table` |
| `oracle-database_list_schemas` | List accessible database schemas (users) in the Oracle Database instance. Returns only non-Oracle-maintained schemas. Use filter_pattern with SQL LIKE wildcards (% and _) to narrow results. | optional `filter_pattern` |
| `oracle-database_list_tables` | List tables and views in a specific Oracle Database schema. Use filter_pattern with SQL LIKE wildcards to narrow results. Set include_views=false to see only tables. | **required** `schema`<br />optional `filter_pattern`, `include_views` |

## Snowflake (JWT)

11 tools. Connect with JWT.

| Tool | Description | Arguments |
| --- | --- | --- |
| `snowflake-jwt_cancel_query` | Cancel a running query by its statement handle. | **required** `statement_handle` |
| `snowflake-jwt_describe_table` | Describe table columns including names, types, nullability, defaults, and comments. | **required** `database`, `schema_name`, `table` |
| `snowflake-jwt_execute_query` | Execute a SQL query on Snowflake. Returns columns and rows for synchronous results, or a statement handle for async queries. Supports parameter bindings and warehouse/database/schema/role overrides. | **required** `statement`<br />optional `bindings`, `database`, `role`, `schema_name`, `timeout`, `warehouse` |
| `snowflake-jwt_get_query_status` | Get the status of a running or completed query by its statement handle. Can also fetch additional result partitions for large result sets. | **required** `statement_handle`<br />optional `partition` |
| `snowflake-jwt_get_warehouse_status` | Get detailed status of a Snowflake warehouse including state, running queries, and queued queries. | **required** `name` |
| `snowflake-jwt_list_databases` | List Snowflake databases accessible to the current role. Supports LIKE pattern filtering. | optional `like` |
| `snowflake-jwt_list_schemas` | List schemas in a Snowflake database. | **required** `database` |
| `snowflake-jwt_list_tables` | List tables in a Snowflake schema with row count, byte size, and clustering info. | **required** `database`, `schema_name` |
| `snowflake-jwt_list_warehouses` | List Snowflake warehouses with name, state, size, and auto-suspend configuration. | — |
| `snowflake-jwt_resume_warehouse` | Resume (start) a suspended Snowflake warehouse. | **required** `name` |
| `snowflake-jwt_suspend_warehouse` | Suspend (stop) a running Snowflake warehouse. | **required** `name` |

## SQL Database

8 tools. Credentials are supplied in the connection settings.

| Tool | Description | Arguments |
| --- | --- | --- |
| `sql-database_describe_table` | Get detailed column metadata for a table: column name, data type, nullability, default value, and whether the column is part of the primary key. Use this to understand a table's structure before querying it. | **required** `table_name`<br />optional `schema` |
| `sql-database_execute_query` | Execute a read-only SQL query against the connected PostgreSQL database and return structured results with column metadata. | **required** `sql`<br />optional `limit`, `timeout_seconds` |
| `sql-database_execute_write` | Execute a write SQL statement (INSERT, UPDATE, DELETE, TRUNCATE, or MERGE) against the connected PostgreSQL database. This tool is only available when the connection has write access enabled (allowWrites: true). | **required** `sql`<br />optional `timeout_seconds` |
| `sql-database_explain_query` | Return the execution plan for a SQL query in JSON format without actually executing the query. | **required** `sql` |
| `sql-database_list_foreign_keys` | List foreign key relationships for a table, showing which columns reference which foreign tables and columns. Useful for understanding table relationships before writing JOIN queries. | **required** `table_name`<br />optional `schema` |
| `sql-database_list_indexes` | List indexes on a table including column names, uniqueness, whether it's a primary key index, and the index type (btree, hash, gin, etc.). | **required** `table_name`<br />optional `schema` |
| `sql-database_list_schemas` | List all schemas in the connected PostgreSQL database, excluding system schemas (pg_catalog, information_schema, pg_toast). Use this to discover what schemas are available before exploring tables. | — |
| `sql-database_list_tables` | List tables and views in a database schema with their type (BASE TABLE or VIEW) and estimated row count. Defaults to the 'public' schema. | optional `schema` |

---

## Business systems

Source: https://docs.kindo.ai/reference/tool-catalog/business-systems/

:::note[Beta]
The tool catalog is in beta and is a point-in-time snapshot of the integration inventory, so an entry can differ from what your organization sees in product.
:::

Business and revenue platforms an agent can read. 3 integrations, 3 tools.

Tool names below are the fully qualified names an agent sees once the integration is connected. Where an integration offers more than one connection, the names shown use the primary connection's prefix; connecting through another variant prefixes its tools with that variant's own integration ID instead. See [Tool Catalog](/reference/tool-catalog/) for how tools are granted and named.

## Salesforce

0 tools. Connect with OAuth 2.0.

## SAP S/4HANA (OData)

1 tool. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `sap-s4hana_sap_odata_query` | Execute OData operations against SAP S/4HANA services. | **required** `serviceName`, `entitySet`<br />optional `customHeaders`, `customQueryParams`, `data`, `entityKey`, `expand`, `filter`, `metadata`, `method`, `orderby`, `pathSuffix`, `select`, `skip`, `top` |

## SAP S/4HANA (RFC)

2 tools. Connect with Basic auth.

| Tool | Description | Arguments |
| --- | --- | --- |
| `sap-s4hana-rfc_get_rfc_metadata` | Get metadata information for an SAP RFC function to discover its parameter structure, types, and documentation. Use this tool first to understand the required parameters before calling an RFC. | **required** `rfcName` |
| `sap-s4hana-rfc_rfc_call` | Execute any SAP Remote Function Call (RFC) with custom parameters. This provides direct access to any SAP RFC module. If you're unsure about the required parameter values and structure, use the get_rfc_metadata tool first before executing. | **required** `rfcName`<br />optional `autoCommit`, `parameters` |

---

## Release Notes

Source: https://docs.kindo.ai/release-notes/

Kindo publishes release notes in two tracks:

- **SaaS** — bi-weekly summaries of what shipped to `app.kindo.ai`. Posted every other Monday.
- **Self-managed (SMK)** — published when a new SMK version is cut. Includes upgrade notes alongside what's new.

## Recent releases

- **SaaS:** see [SaaS release notes](/release-notes/saas/) for the latest bi-weekly summaries.

## How to read these notes

Each release describes what changed from your perspective as a Kindo customer or admin. We focus on:

- New capabilities and integrations
- Improvements to performance, reliability, and accuracy
- Customer-observable bug fixes
- For SMK only: upgrade notes and operator-relevant changes

We do not enumerate every ticket. Each release is authored from a tracked backlog item for internal auditability; the published copy itself stays source-link-free so each release reads in under three minutes.

## Feedback

Spot something missing or unclear? Reach out via [support@kindo.ai](mailto:support@kindo.ai) — or, if you have a shared Slack channel with Kindo, open a thread there. We re-tune the format every cycle based on what readers tell us.

---

## SaaS Release Notes

Source: https://docs.kindo.ai/release-notes/saas/

Kindo publishes SaaS release notes every other Monday, covering the previous two weeks of customer-facing changes.

## Recent releases

- [2026-08-30](/release-notes/saas/2026-08-30/) — **AI spend in dollars**, more reliable tool access, expanded security integrations, and stronger admin governance
- [2026-08-16](/release-notes/saas/2026-08-16/) — **Unified sign-in and SAML administration**, Command Center tabs with AI Spend reporting, expanded integrations, and reliability fixes
- [2026-08-02](/release-notes/saas/2026-08-02/) — **Memory for chats and agents**, Kimi K3, webhook-triggered run handles, expanded integrations, and clearer spend views
- [2026-07-19](/release-notes/saas/2026-07-19/) — **Per-integration Demo controls**, failed-step retries, expanded integrations, model and telemetry controls, and reliability fixes
- [2026-07-05](/release-notes/saas/2026-07-05/) — **Invoke Kindo agents from any OpenAI Responses client**, resumable response streams, refreshed API reference docs, and Anthropic-endpoint compatibility fixes
- [2026-06-21](/release-notes/saas/2026-06-21/) — **Collapsed chat tool activity**, **Claude Opus 4.8**, chat history search, expanded MCP integrations, Microsoft setup docs, and reliability fixes
- [2026-06-07](/release-notes/saas/2026-06-07/) — **Persistent workspaces** for agents, more resilient sandboxes, safer integration updates, clearer chat errors, and expanded Jira and Nagios coverage
- [2026-05-24](/release-notes/saas/2026-05-24/) — **Agent run objective evaluations**, workflow version history, pinned integration connections, and expanded access controls
- [2026-05-10](/release-notes/saas/2026-05-10/) — Command Center stats for unlimited-credit orgs, larger workflow payloads, Microsoft Outlook listing, ServiceNow & Freshservice depth
- [2026-04-26](/release-notes/saas/2026-04-26/) — **Light mode** and the **Chat Actions public API** launch, plus a major Traceable AI integration expansion
- [2026-04-12](/release-notes/saas/2026-04-12/) — New integrations (Oracle Database, Cloudflare, Rapid7, Cofense Triage, Qualys), Canvas AI disclaimer, several chat-reliability improvements
- [2026-03-29](/release-notes/saas/2026-03-29/) — **Agent Stats** analytics dashboard, new integrations (Horizon3, FireHydrant, Confluence, Freshservice, Dynatrace), integration reliability improvements

## Cadence

| Field | Value |
|---|---|
| Frequency | Every two weeks |
| Window | Monday 00:00 PT through second following Sunday 23:59 PT |
| Publish day | Following Monday |

---

## "SaaS Release — 2026-08-17 to 2026-08-30"

Source: https://docs.kindo.ai/release-notes/saas/2026-08-30/

_Window: 2026-08-17 → 2026-08-30_

## Highlights

### AI spend in dollars

Admins can review model spend in dollars alongside credit usage. The AI Spend dashboard includes cost-aware analytics so teams can understand real inference spend, including calls that use customer-provided model access.

### More reliable tool access for large integration sets

Agents with many available tools use a more scalable tool-discovery path instead of sending an oversized tool list to the model. This improves reliability for agents connected to broad integrations and reduces cases where an important tool disappears from a run. The unused MCP Prompts surface has also been removed so connected clients focus on supported tool operations.

## Integrations

### Microsoft government cloud and Entra ID coverage

Microsoft integrations support more government-cloud tenant scenarios, including Azure Government and GCC High variants across Microsoft cloud services. Entra ID coverage also expands with reporting tools for application activity, credential usage, tenant recommendations, and SLA status.

### Expanded security and identity integrations

Kindo adds broader cloud, identity, and security-operation coverage across key integrations:

- AWS and Google Cloud security tools for cloud-asset investigation and action.
- SailPoint task-status, result-retrieval, and policy-governed operational tools.

## Improvements

### Stronger admin governance and self-service troubleshooting

Organization settings are easier to navigate: Model Access and DLP, Integration and Tool controls, Audit Log, Sharing Permissions, and Agent Telemetry Export appear as first-level Organization settings instead of being nested under a Security group. Audit logs also capture integration connection and deletion events, and the public MCP gateway applies organization policy and DLP controls before returning tool results. Agent run pages also show the Inspect view and identify the failing step more clearly when a run fails.

### More model and API control

DeepSeek V4 Pro is updated to the 0813 revision, with a larger context window and lower listed provider pricing. DeepHat V3 can be enabled as a centrally managed model option, direct DeepHat API usage can be tracked with account-level credentials, and chat-completion API calls honor JSON response-format requests more consistently.

### Public setup and API documentation

Kindo's SSO setup guides for Microsoft Entra ID, Okta, and Google Workspace are hosted directly in the docs site. The Conversations API documentation also clarifies that item-reading endpoints apply to any authorized conversation, not only conversations created through the Responses API. Agent documentation also covers more agent types, scheduled runs, direct webhook triggers, programmatic execution, and best-practice cross-links.

## Fixes

### Reliability fixes for agent work, auth, uploads, and ingestion

This release includes several customer-observable fixes:

- Long-running agent conversations are less likely to dead-end after a tool call, and persistent workspaces are less likely to lose artifacts during multi-session work.
- Chat persistence handles transaction conflicts more gracefully instead of failing the run.
- Email sign-in code delivery, invited-user sign-in, and knowledge-base file uploads are more reliable.
- Oversized API requests return a clear `413 Payload Too Large` response instead of an opaque server error.
- File ingestion handles provider-specific embedding limits more safely.
- Integration tool discovery recovers from rollout regressions that previously made some integration capabilities appear unavailable.

---

## "SaaS Release — 2026-08-03 to 2026-08-16"

Source: https://docs.kindo.ai/release-notes/saas/2026-08-16/

_Window: 2026-08-03 → 2026-08-16_

## Highlights

### Unified sign-in and SAML administration

Kindo's sign-in foundation is consolidated across email, social login, SSO, sessions, and API keys. Admins get a cleaner SAML setup path with service-provider metadata exposed in the SSO settings experience, while users get polished login screens and more consistent sign-in behavior.

The release also tightens API-key access controls so user-group restrictions are enforced consistently across request paths.

### Command Center tabs and AI Spend reporting

Command Center is organized into focused tabs for Agent Monitoring, Usage Statistics, Integrations, and AI Spend. Organization-level spend reporting is available from the same admin area as the rest of Command Center, with chart and layout updates that make the page easier to scan.

## Integrations

### New and expanded integration coverage

Kindo expanded the integration catalog and several high-priority connector surfaces:

- Amazon S3, AWS CloudWatch, and CyberArk are available as new integration targets.
- Okta includes write and create actions for users, groups, applications, policies, and policy rules.
- Qualys includes Cloud Agent lifecycle coverage.

Standard integrations also return clearer authorization details when an API denies access, so users see the provider's specific reason instead of a generic denial.

### Integration reliability fixes

Resolved connector issues that blocked normal agent work:

- Swimlane app and record tools handle valid app and record identifiers more reliably.
- Wiz tool responses are normalized when the upstream server returns schema-incompatible output.

## Improvements

### Clearer customer-managed model errors

Model-provider errors are easier to triage when a customer-managed provider hits its own rate limits or failures. Error copy distinguishes provider-side failures from Kindo platform failures, helping users route the problem to the right administrator or model owner.

A multimodal Qwen model option is available for organizations that need Qwen-based model coverage for image and file inputs.

## Fixes

### Safer agent run continuations

Continuing a historical agent run preserves the original integration connection context instead of switching to the viewer's current connection. This keeps continued runs tied to the same connected account and data scope as the original run.

### Sign-in recovery fixes

Resolved an issue where valid one-time sign-in codes and email links could be rejected as invalid or expired. Additional login polish improves button spacing, colors, and production copy across the consolidated sign-in experience.

---

## "SaaS Release — 2026-07-20 to 2026-08-02"

Source: https://docs.kindo.ai/release-notes/saas/2026-08-02/

_Window: 2026-07-20 → 2026-08-02_

## Highlights

### Memory for chats and agents

Kindo memory is a governed product capability for chats and agents. Users can see when memory is enabled, manage remembered information, and opt out; admins can enable or disable memory for the organization and clear stored memory when needed. The memory backend is more durable across runs while preserving ownership and erasure controls.

### Kimi K3 model support

Kimi K3 is available in Kindo model selection surfaces and public APIs. Teams can use Moonshot AI's Kimi K3 in agents and API automations alongside the rest of the supported model catalog.

### Track webhook-triggered agent runs

Direct webhook agent triggers return a Responses API run handle. Callers can use the handle to check status, poll output, and connect follow-up automation to the run they started.

## Integrations

### Broader MCP integration coverage

Kindo added or expanded MCP tool coverage across several commonly used systems:

- ServiceNow: read record attachments and attach CSV outputs to incident tickets.
- Qualys: Container Security coverage, policy-compliance scan schedules, and clearer authentication errors.
- Saviynt: connector coverage for provisioning, job/task lookup, and identity-lifecycle workflows.
- Google SecOps: create and list reference lists.
- Linear and GitHub: initiative/project traversal, Dependabot and security alerts, and pull-request conflict workflows.

### More reliable Microsoft and endpoint-security integrations

Microsoft connection setup lets users choose the account to connect instead of silently reusing the browser's existing Microsoft session. Microsoft Teams, SharePoint, CrowdStrike Falcon, and Guardicore flows return more accurate policy data or clearer error messages when something needs attention.

## Improvements

### Clearer spend and Command Center review

Credit displays include USD equivalents, making spend easier to understand at a glance. Command Center keeps the Personal/Org-Wide scope selector visible while scrolling and shows a clearer Personal-scope empty state instead of making the statistics section disappear.

### Smoother search and interactive controls

Search fields use consistent leading search icons, and chat sidebar search fields align with the rest of the app's text-field styling. Rapid clicks on buttons, tabs, toggles, and similar controls no longer flash accidental text-selection highlights.

## Fixes

### More accurate agent-run status and recovery

Agent runs that fail abruptly move to a failed state instead of remaining stuck in progress. Durable child-agent execution is restored for long-running work, and model-stream failures surface as clearer chat errors instead of leaving the run opaque.

### More reliable credit aggregation

Resolved a credit-aggregation overflow issue that could leave high-volume usage rows unaggregated and increase database load. Credit summaries are now more stable for organizations with large transaction volumes.

---

## "SaaS Release — 2026-07-06 to 2026-07-19"

Source: https://docs.kindo.ai/release-notes/saas/2026-07-19/

_Window: 2026-07-06 → 2026-07-19_

## Highlights

### Per-integration Demo controls

Chats and multi-step agents can combine Demo tools with live integration connections. Each integration has its own Demo toggle, so teams can test selected integrations with sample data while keeping the rest connected to live systems.

### Retry a failed agent step

When a multi-step agent fails, users can retry the failed step in place instead of restarting the entire run. Results from earlier successful steps remain available for the retry.

## Integrations

### New security, data, and identity integrations

Kindo expanded its integration catalog with:

- ExtraHop RevealX for network detections, devices, records, and investigations.
- Microsoft Azure for cloud security, policy, resource, RBAC, management-group, and posture data.
- Supabase for database, authentication, and storage operations.
- Proofpoint Email Protection for message investigation and quarantine operations.
- Delinea Secret Server and Cyera DSPM for secrets and data-security workflows.
- Connectable, verified configurations for Doppler and Zendesk.

### Broader operations across existing integrations

Existing integrations gained additional capabilities and reliability improvements:

- Qualys supports broader API access and Global AssetView operations.
- CrowdStrike Falcon adds identity, endpoint-response, zero-trust, and policy-membership operations.
- Microsoft Teams can list and retrieve meeting transcripts, and the Microsoft eDiscovery guide covers application-mode setup.
- Linear supports archiving, restoring, and deleting issues through its integration tools.
- File-upload tools across supported integrations use signed file references, avoiding truncation for larger files.

## Improvements

### Governed early access for integrations

New integrations remain hidden from general use until they are verified. Approved organizations can access selected integrations early, with clear Early Access badges, while existing connections remain available during verification.

### More model and telemetry control

GLM 5.2 is available in the SaaS model catalog, and model settings expose the canonical API identifier for each model. Admins can also route agent telemetry to organization-specific OpenTelemetry destinations without mixing data between organizations.

## Fixes

### More reliable chat results, files, and API errors

This release includes several customer-observable fixes:

- Agent output remains visible after refreshing a chat, and child-agent run links open the correct run.
- Generated files appear as authenticated downloads instead of inaccessible storage links.
- Follow-up chat turns keep working for agents that have a very large set of authorized tools.
- Binary attachments blocked by DLP return a clear client error instead of a generic server error.
- Sandboxes recover more reliably when an archival operation stalls.

---

## "SaaS Release — 2026-06-22 to 2026-07-05"

Source: https://docs.kindo.ai/release-notes/saas/2026-07-05/

_Window: 2026-06-22 → 2026-07-05_

## Highlights

### Invoke Kindo agents from any OpenAI Responses client

The Agents API extension of the Responses API is complete. Any stored Kindo agent can be invoked from a stock OpenAI Responses client by passing its ID as the model (`agent/<agent-id>`) — the agent supplies the model, system prompt, and tools; the caller supplies the task. The capability set includes:

- Agent discovery alongside the model catalog (`include_agents=true` on the models list, with pagination for large agent fleets).
- Live streaming of run activity — assistant text, reasoning summaries, and tool calls stream as standard Responses output items while the run executes.
- Polling for long-horizon runs, with run output populated incrementally as the run progresses.
- Full run transcripts readable through the Conversations API, including tool-call detail.

See the [agent invocation guide](/guides/invoke-agents-responses-api/) to get started.

## Integrations

No integration changes to report in this window yet.

## Improvements

### Resumable response streams

If a streamed Responses API connection drops mid-response, clients can reconnect to the same response and replay the events they missed instead of starting over — every streamed event carries a sequence number, and browser `EventSource` clients resume automatically. Agent-run responses replay from the beginning of the run and then continue live. See [Responses API streaming](/apis/responses/streaming/#resuming-a-dropped-stream).

### Refreshed API reference documentation

The public API reference was audited against the live API surface at the conclusion of the Agents API project: streaming event vocabulary, conversation item types, message content parts (including file and image inputs), and run trigger semantics are all documented to match current behavior.

## Fixes

### Anthropic endpoint compatibility with OpenAI-style clients

The Anthropic-compatible messages endpoint accepts payloads produced by OpenAI-style gateways and SDK shims: system-role entries inside the messages array are honored as system prompts, and messages without an explicit role are treated as user messages. Clients that previously saw validation rejections now work unmodified.

---

## "SaaS Release — 2026-06-08 to 2026-06-21"

Source: https://docs.kindo.ai/release-notes/saas/2026-06-21/

_Window: 2026-06-08 → 2026-06-21_

## Highlights

### Collapsed tool activity in chat

Chat responses now group tool activity into a compact activity card instead of rendering every tool call as a full inline card. Users can scan what the agent is doing, see error counts, and expand details when they need the full inputs and results.

### Claude Opus 4.8 availability

Kindo now supports Claude Opus 4.8 as a globally available model. Admins and users can choose it where their organization's model policy allows it, giving long-context agent runs access to a stronger reasoning model.

### Chat history search

The chat history sidebar now supports searching past conversations by title. Results are filtered across the full paginated history, so users can find earlier work without manually loading and scanning each page.

## Integrations

### New and expanded MCP integration coverage

Kindo expanded MCP coverage for several enterprise systems and connector types:

- Bitbucket, Harness, BitSight, Rapid7 InsightVM Cloud, and Cisco Secure Network Analytics integrations are now available.
- Python-based MCP servers are now supported in Kindo.
- The SQL Database integration now supports PostgreSQL connections and write-capable use cases where enabled.

### Jira, Freshservice, Google SecOps, and ServiceNow enhancements

Several existing integrations gained more complete tool coverage:

- Jira tools now support internal comments, issue attachments, and more reliable priority handling during issue creation.
- Freshservice tools now support adding notes, attaching files, and replying to tickets.
- Google SecOps parser creation and parser run tools now expose the required inputs correctly.
- ServiceNow image analysis flows now proceed without requiring an extra user prompt after an image is downloaded.

### File connector improvements

SharePoint, OneDrive, Box, and Dropbox file operations are more complete and reliable. SharePoint can better discover lists and upload attached documents from chat, OneDrive uploads no longer truncate larger content, and shared file-download tooling now accepts more common developer file types.

## Improvements

### Public docs and Microsoft setup guidance

The public docs now include restored API reference coverage for agents, runs, conversations, models, and integrations. Kindo also added public setup guidance for Microsoft MCP integrations, including the Microsoft Entra app registration and Kindo connection steps needed for Microsoft Graph-backed connectors.

## Fixes

### Reliability fixes across chats, files, DLP, and docs

Resolved several customer-observable issues from this release window:

- Agent runs are more resilient to provider timeouts, stale run state, and submitted messages that could previously appear to stall or disappear.
- Demo-mode tool execution and Salesforce connector availability are more reliable.
- DLP-protected chats and model-access denials now return clearer, more appropriate errors.
- File uploads and audit-log CSV exports no longer fail on a malformed XML parsing edge case.
- The public docs site now renders light mode and Markdown tables correctly.

---

## "SaaS Release — 2026-05-25 to 2026-06-07"

Source: https://docs.kindo.ai/release-notes/saas/2026-06-07/

_Window: 2026-05-25 → 2026-06-07_

## Highlights

### Persistent workspaces for agents

Agents can now use persistent workspaces so files and execution state can carry across runs when the selected sandbox mode supports persistence. The agent configuration UI marks the capability as beta and disables it automatically for non-persistent sandbox modes.

### More resilient sandbox execution

Sandbox-backed agent work now handles missing or expired sandboxes more gracefully. Kindo also improved runtime recovery for degraded sandbox environments, reducing cases where new sandbox work could fail because underlying runtime state drifted.

## Integrations

### Jira: richer issue updates and attachment reading

The Jira integration now supports more system fields when updating issues, including fields such as priority, assignee, and labels where the Jira instance allows them. Agents can also read attachment content from Jira issues, making screenshots, logs, and supporting documents available to the workflow.

### Nagios integration

Kindo added Nagios MCP integration support, giving agents access to infrastructure monitoring context from Nagios-backed environments.

### SharePoint file upload reliability

SharePoint uploads now preserve binary file content for formats such as documents, spreadsheets, and PDFs. This resolves a corruption issue that only affected binary uploads, while text uploads were already working.

### Microsoft Entra and Google Drive error handling

Microsoft Entra ID now handles unsupported user-sort fields with clearer validation, and Google Drive errors are wrapped more consistently with the rest of the Google integration family. Both changes make integration failures easier for agents and users to interpret.

## Improvements

### Clearer failed-chat logging

Kindo now avoids misleading internal failure messages when a chat failure is already captured with a specific Kindo error code. This improves diagnostics and helps support distinguish the actual user-facing error from follow-on persistence noise.

### Audit log export diagnostics

Audit-log export workflows now include stronger error logging, improving supportability when an export fails and reducing the amount of follow-up needed to understand where it stopped.

## Fixes

### Workflow configuration wizard completion

Resolved an issue where the workflow configuration wizard could instruct the model to call a completion tool that was not available. The wizard no longer gets blocked on that phantom tool reference.

### DLP-related chat errors

DLP provider errors no longer crash the OpenAPI response serializer. DLP-enabled chats now surface the intended Kindo error path instead of a generic unexpected-error response caused by circular error data.

### MP4 attachments in Claude conversations

Chats with MP4 attachments now fail more cleanly instead of exposing low-level internal error details from the model request path.

### Triggered-agent run visibility

Users running triggered agents shared with them can now see the resulting runs instead of an empty recent-runs state.

---

## "SaaS Release — 2026-05-11 to 2026-05-24"

Source: https://docs.kindo.ai/release-notes/saas/2026-05-24/

_Window: 2026-05-11 → 2026-05-24_

## Highlights

### Agent run objective evaluations

Command Center can now show whether an agent run met its intended objective, separate from whether the run completed technically. Admins can inspect per-step verdicts and reasoning, see objective status in run lists and details, and use audit events for compliance review.

### Workflow version history and restore

Agent and workflow edits now create version snapshots that can be reviewed later. Builders can inspect historical versions, restore a previous version, and rely on audit logging around restore actions.

### Pinned integration connections for shared workflows

Workflow builders can pin specific integration connections to a workflow step, allowing a shared workflow to run with the intended connection rather than silently falling back to the runner's default connection. Kindo now hard-fails unavailable pinned connections with a clear error and records which connection was used in audit logs.

## Integrations

### New and expanded integration coverage

Kindo added or expanded integration coverage across security, ITSM, DLP, monitoring, and developer operations surfaces, including CrowdStrike Falcon Sandbox, Trellix Endpoint Security, Rapid7 InsightCloudSec, Rapid7 InsightVM, Zabbix, Wazuh, Cyble Vision, Burp Suite, MITRE ATT&CK, Cyberhaven, Armis, Zendesk Support Suite, Freshservice, and ServiceNow trigger support.

### Microsoft integrations: Fabric and Entra reliability

Microsoft Fabric and Microsoft Entra ID integrations received fixes for authentication and data-access reliability. This improves agent access to Microsoft-backed identity and data workflows that previously could fail before the agent reached the useful work.

### Jira and Splunk tool improvements

Jira transitions now support workflows that require additional fields, and Splunk Enterprise Security updates now better handle status, owner, and disposition changes. These improvements make Kindo agents more useful in ticket and finding workflows where the target system enforces custom process requirements.

## Improvements

### Expanded user-group controls

Admins now have more granular user-group controls for agent access, file uploads, personal API key creation, free-form chat availability, and integration credential use. Shared agents can be scoped more precisely, and Kindo now warns users when a shared agent depends on tool connections unavailable to them.

### Personal API keys with clearer attribution

Non-admin users can now generate personal API keys where enabled by policy. Activity from those keys is attributed to the actual user rather than requiring an admin-owned key for every API workflow.

### Command Center usage and filtering polish

Command Center gained a user filter for recent agent runs and clearer status tooltips, making it easier for admins to understand who triggered runs and what each status column means.

### Tool policy layout polish

The Tool Policies dialog now aligns connection dropdowns and badges more consistently, improving readability when managing tool access across multiple integrations.

### Scheduled agent limits documented

Kindo now documents and surfaces limits around scheduled agents, helping admins understand scale expectations before configuring large scheduled-agent fleets.

## Fixes

### Clearer context-window errors in chat

Context-window failures now map to a more precise chat error instead of a generic failure. Users get a clearer explanation when a conversation or request has grown beyond the active model's limits.

### Chat Actions audio transcription

Audio transcription in Chat Actions now initializes correctly in the worker path. Audio and video files that depend on transcription no longer fail silently because the transcription provider was unavailable to the task.

### Workflow Builder user-input editing

Resolved an issue where editing a workflow step after adding a direct trigger could fail when the step referenced user inputs.

### Long-running chat tool calls

Streaming chat sessions now remain healthier during long-running tool execution. Kindo sends keepalive traffic so the browser connection is less likely to drop while an agent is still working.

### File upload reliability

PDF uploads no longer fail after reaching storage because of response-parsing errors in the upload path.

### Light mode visual polish

Additional light-mode polish resolved invisible containers and dark-mode skeleton states that could make loading or stalled content look like redacted content.

---

## "SaaS Release — 2026-04-27 to 2026-05-10"

Source: https://docs.kindo.ai/release-notes/saas/2026-05-10/

_Window: 2026-04-27 → 2026-05-10_

## Highlights

_No headline features this cycle — see Integrations, Improvements, and Fixes below._

## Integrations

### Microsoft Outlook: list available email addresses

The Microsoft Outlook Email integration can now enumerate the email addresses a connected account has access to, making downstream address selection in agents more reliable.

### ServiceNow: knowledge-base custom field updates

ServiceNow knowledge-base article updates now support custom fields, including markdown-typed fields. This unblocks workflows that need to write to instance-specific KB schemas.

### Freshservice: Service Catalog APIs

The Freshservice integration now exposes Service Catalog tools (requested items, service catalog items) alongside the existing ticketing surface.

### Guardicore: refresh-token authentication

Guardicore connections now support refresh-token authentication in addition to Basic auth, simplifying long-lived deployments where rotating credentials would otherwise be needed.

## Improvements

### Command Center: credit and token usage for unlimited-credit orgs

Command Center now shows credit and token usage stats for organizations on unlimited-credit billing. These panels previously appeared blank for those orgs, hiding visibility into actual usage.

### Tab and sidebar navigation polish

Hover and selected states across the tab and sidebar navigation are clearer and more consistent.

### Org Security: clearer Default Settings copy

The copy in the Org Security panels (Integrations / Tools and Providers / Models) now more clearly explains what "default" means and how it interacts with per-user overrides.

### Removed the legacy `send_email` tool

The legacy `send_email` tool has been removed from the default tool set. Email-sending workflows should use the supported Gmail or Microsoft 365 integrations, which provide richer authentication and audit controls.

### Larger workflow outputs handled cleanly

Workflow outputs that exceed the platform's per-message size limit now fail fast with a clear error, instead of producing a problematic message that could affect workflow throughput. Workflows that produce smaller outputs are unaffected.

### More reliable long-running background work

Long-running background tasks now remain healthy across extended idle periods. A class of intermittent connection-drop errors that some longer-running workflows occasionally hit has been resolved.

### Stop request on inactive conversations

Requests to stop a chat that is not in a stoppable state now return a precise client-side error indicating the conversation cannot currently be stopped, instead of a generic failure.

## Fixes

### Markdown content: no more indefinite loading on render failure

If the Markdown renderer fails to load, the chat now shows a clear error state and recovers on retry, instead of displaying indefinite skeleton placeholders.

### Intercom widget and chat for users with no cookie consent

A change in cookie-consent handling had broken the Intercom widget and Kindo chat for users who had denied or not yet answered the consent prompt. Both flows now work regardless of consent state.

### Model IDs in API responses: consistent provider prefixes

API responses that include model identifiers now consistently include the provider prefix (for example `anthropic/claude-3-sonnet`), bringing them into parity with the rest of Kindo's model handling.

---

## "SaaS Release — 2026-04-13 to 2026-04-26"

Source: https://docs.kindo.ai/release-notes/saas/2026-04-26/

_Window: 2026-04-13 → 2026-04-26_

## Highlights

### Light mode for Kindo

Kindo's chat interface now supports a system-aware light theme alongside the default dark theme. You can switch themes from your profile menu, or have Kindo follow your operating system's appearance setting. Your existing keyboard shortcuts, chat history, and integrations are unchanged.

### Chat Actions: now available via the public API

You can now invoke Kindo chat actions programmatically. Send a POST to `/v1/responses` with your action's input and receive a streaming response that closely matches the OpenAI Responses API shape, including function tools, persistent sessions, and reusable conversation IDs. Authentication uses your standard Kindo Bearer token.

The new API endpoints include:

- `POST /v1/responses` — invoke a chat action and stream its result
- `GET /v1/responses/{id}` — fetch an existing response
- `GET /v1/conversations/{id}/items` — list conversation items

See the [Responses API quickstart](/apis/responses/quickstart/) for examples and SDK compatibility notes.

## Integrations

### Traceable AI: comprehensive API coverage

The Traceable AI integration now covers nearly the full Traceable platform surface. New capability areas include:

- **Threat & vulnerability management** — query and update vulnerability state, retrieve threat-activity trends, manage detection exclusions.
- **Identity & access management** — full read and write APIs on users, roles, and service accounts.
- **Policy & rule management** — protection rules (IP range, region, rate limiting, malicious sources), custom signature rules, span rules, naming rules.
- **Data classification & redaction** — read and write APIs for classification policies.
- **Anomaly detection & alerting** — configuration APIs and alert/notification management.
- **Observability** — spans, traces, and events query APIs, plus a natural-language query endpoint.
- **Operational tooling** — agent token management, TLS certificate management, sampling configuration, user attribution.

### New and improved integrations

- **Monday.com** — new integration for boards, items, and updates.
- **GitHub Actions** — new integration for workflow runs and job inspection.
- **Freshworks** — new standard integration.
- **CrowdStrike Falcon: Custom IOC Management** — four new tools for managing custom indicators of compromise.
- **OneDrive** — file-path-based upload variant that supports large uploads which previously hit a payload size limit.

### LLM vision for images returned by integration tools

When an integration tool returns an image, Kindo now passes it through to the language model with vision enabled. Tools that return screenshots, charts, or document previews are now interpretable by the agent rather than appearing as opaque attachments.

## Improvements

### Profile dropdown: organization name visible to all users

The profile dropdown now shows your organization name regardless of role, so non-admin users no longer have to guess which Kindo workspace they're in.

### Dropdown and selection polish

Dropdown menus and selection controls have refreshed animations and clearer hover/active states across the app.

## Fixes

### Workflow list reliability

A workflow list endpoint that returned errors for some users in certain conditions has been fixed. Workflow lists now load reliably across all org sizes.

### Anthropic invalid-request errors no longer mislabeled as outages

When the upstream model rejects a request as invalid, the chat now surfaces a precise error indicating the request itself needs adjustment, instead of misreporting the situation as a provider outage.

### Knowledge store: clearer feedback on unsupported file types

Uploading XLSX, CSV, or XLS files to the knowledge store now returns a clear, immediate error at upload time, instead of silently accepting the file and failing later at search time.

### Scheduled Agents respect timezone and frequency

Scheduled Agents now run on the timezone and frequency configured in the UI. Previously these fields could be ignored, resulting in runs at unexpected times.

### Agent Builder: LLM step prompt input is clickable when blank

The LLM step prompt input is now clickable when blank. A visual overlay that made the field appear active but unresponsive has been resolved.

### GitHub integration: large file uploads

Large file uploads through the GitHub integration now complete cleanly or fail with a clear size-limit error, instead of silently producing corrupt content.

### API Action Step: previous step outputs available

API Action Step bodies can now reference the outputs of previous steps in a workflow. Previously this context was empty during body evaluation.

### SAP integration: serialization reliability

A serialization regression affecting some SAP on-prem instances has been resolved. SAP-backed workflows now serialize responses reliably.

---

## "SaaS Release — 2026-03-30 to 2026-04-12"

Source: https://docs.kindo.ai/release-notes/saas/2026-04-12/

_Window: 2026-03-30 → 2026-04-12_

## Highlights

_No headline features this cycle — see Integrations, Improvements, and Fixes below._

## Integrations

### New integrations available

- **Oracle Database** — query Oracle databases via Kindo.
- **Cloudflare** — read-only tool suite covering 35 tools across DNS, Workers, security, and analytics.
- **Rapid7 InsightAppSec** — application security scans and findings.
- **Cofense Triage** — phishing-report triage.
- **Qualys VMDR & Policy Compliance** — vulnerability management and policy compliance reads.

### SAP integration: connection parameters for on-prem instances

The SAP integration now accepts Hostname, Instance Number, and Client parameters when connecting to on-prem SAP instances, in addition to the existing SAP Cloud Platform connection mode.

## Improvements

### Canvas: AI disclaimer banner

Canvas pages now include a sticky AI-disclaimer banner that clearly identifies AI-generated content, complementing the existing per-message attribution.

### Page-specific browser tab titles

Browser tab titles now reflect the specific page or chat you're viewing inside `app.kindo.ai`, making it easier to navigate when you have several Kindo tabs open.

### Long-context Claude conversations: continuity preserved

We migrated our long-context Claude usage onto Anthropic's stable extended-context path ahead of the prior beta retirement. Long-context Claude conversations continue to work without interruption.

## Fixes

### Clearer chat error messages

Chat errors now surface clearer, more actionable messages instead of a generic failure. Provider outages, access-denied conditions, and responses that approach the model's output limit now finalize with a clear explanation of what happened and how to proceed.

### Direct webhook triggers in workflows

The Direct Webhook URL trigger now evaluates correctly under the conditions configured in the workflow editor. Workflows that depended on this trigger now fire reliably.

### Chat image URLs persist for the life of the conversation

Images shared in chat no longer break or become unreachable in long-lived conversations; image URLs are refreshed before they're served so images remain accessible throughout the chat.

### Tool Policies UI: ACTIVE toggle visibility

The ACTIVE toggle in the Tool Policies UI is now clearly visible and clickable. A layout issue that obscured it has been resolved.

### Command Center: rename integration connections

You can now rename your integration connections from Command Center. Previously the rename action failed.

### Larger Claude Sonnet 4.6 context window on Bedrock

Bedrock-backed Claude Sonnet 4.6 deployments now correctly advertise the model's extended 1M-token context window, matching what the underlying model supports.

### Deprecated model surfacing

Models that have been deprecated by their provider no longer trigger repeated error indicators on every call. Deprecated models now surface a clean warning and route to a supported alternative where one is configured.

---

## "SaaS Release — 2026-03-16 to 2026-03-29"

Source: https://docs.kindo.ai/release-notes/saas/2026-03-29/

_Window: 2026-03-16 → 2026-03-29_

## Highlights

### Agent Stats analytics dashboard

Kindo's Command Center now includes an Agent Stats dashboard that surfaces credit and token usage across your org, broken down by transaction type and model. You can group results, drill into individual time series, and see the top model in use at a glance.

## Integrations

### New integrations available

We added five new integrations this cycle. All are available through the standard Tools & Integrations flow:

- **Horizon3 NodeZero** — pentest runner discovery and run listing
- **FireHydrant** — incident management
- **Confluence** — pages and spaces
- **Freshservice (Freshdesk)** — ticketing and service catalog
- **Dynatrace** — observability and monitoring

### Microsoft Graph: reset a user's Identity Protection risk score

The Microsoft Graph integration can now dismiss a user's Identity Protection risk score programmatically, in addition to the existing read-only risk and sign-in queries.

### Traceable AI integration expanded

The Traceable AI integration covers significantly more of the Traceable platform surface this cycle, laying the groundwork for the broader Traceable expansion you'll see in the next release.

## Improvements

### Higher per-step tool call limit

The maximum number of tool calls a single agent step can make is now 200 (previously 100). This unblocks longer browser-driven workflows and agents that orchestrate many tool calls within a single step.

### Connection setup instructions in the docs

We added connection-setup instructions for several integrations to the docs portal so you can self-serve the connection flow without going back to your account team.

### Clearer attribution for Command Center agent runs

Command Center now makes it clearer which user identity is associated with a triggered agent run, reducing confusion when reviewing run history across team members.

## Fixes

### CrowdStrike Falcon reliability

The CrowdStrike Falcon integration is now significantly more reliable. Workflows that depend on Falcon — incident retrieval, alert handling, and downstream actions — complete cleanly where they previously failed intermittently.

### Org invite emails now resolve consistently

Accepting an organization invitation now works regardless of email casing. Invitations sent to one casing of an email and accepted from another no longer fail to resolve.

### Jira Data Center: Basic auth restored

A regression that prevented Jira Data Center connections using Basic authentication from working has been fixed. Basic auth against Jira Data Center now connects as expected.

### Google Sheets: shared spreadsheet text rendering

The Google Sheets integration now returns clean, consistent text for shared spreadsheets. Earlier intermittent garbling on shared sheets has been resolved.

### Chat reliability fixes

- Chats that previously failed with a generic error when an assistant prefill was rejected by the model now complete normally.
- The Tool Server search field now works correctly when the query contains a space.
- Converting a chat into an agent no longer times out before handing off to the builder for some long-running conversations.