> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cobalt.peoplereign.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Capabilities overview

> Which capability to configure for a given use case — Apps, MCP Servers, External Agents, Knowledge, or Skillsets.

# Capabilities overview

An agent's capabilities are the things it can **know** and **do**. There are
several ways to grant them, and they aren't interchangeable — start at the top
and work down, taking the first one that genuinely covers your use case.

## Which one do I need?

```mermaid theme={null}
flowchart TD
  Start([What do you want the agent to do?]) --> Q1
  Q1{"Does a Cobalt App<br/>do what you need?"}
  Q1 -->|Yes| A1["Add the App"]
  Q1 -->|No| Q2
  Q2{"Is there an MCP Server or<br/>External Agent that covers it?"}
  Q2 -->|Yes| A2["Add the MCP Server<br/>or External Agent"]
  Q2 -->|No| Q3
  Q3{"Are the answers in a few documents<br/>you can upload and keep current?"}
  Q3 -->|Yes| A3["Create a Knowledge collection"]
  Q3 -->|No| Q4
  Q4{"Can the agent already do it, if<br/>you write down the procedure?"}
  Q4 -->|Yes| A4["Author a Skillset"]
  Q4 -->|No| A5["Contact support"]
```

### Add the App

Cobalt builds and maintains the integration for you — Jira, ServiceNow, Workday,
Slack and the rest of the [catalog](/integrations/catalog). Pick it, authorize
it, and your agent gets a vetted, policy-gated set of tools that Cobalt keeps
working as the vendor's API changes.

<Warning>
  Having an App for your vendor isn't the same as the App doing your job. Open
  the App's page and read what its tools actually do before you commit. If your
  use case needs something they don't cover, treat this as a **no** and keep
  going down the chart — you can still add the App for what it *does* cover and
  handle the rest further down.
</Warning>

→ [Integrations overview](/integrations/overview)

### Add the MCP Server or External Agent

No Cobalt App fits, but your vendor or your own team already runs something you
can point at. An [MCP Server](/integrations/mcp-server) gives your agent tools it
runs itself — you supply a URL and Cobalt discovers what's there. An External
Agent is a peer agent your agent hands part of a conversation to.

You don't write the logic here, but you own the server it lives on, so the same
fit test applies: check what its tools actually do before you commit.

→ [MCP servers](/integrations/mcp-server) · [Integrations overview](/integrations/overview)

### Create a Knowledge collection

The answer lives in documents rather than in a system: an employee handbook, a
handful of policy PDFs, an internal FAQ. Choose this when the set is small enough
that you're happy uploading the files yourself and re-uploading them when they
change — a few dozen documents that turn over occasionally, not a live library of
thousands.

The agent searches this content and cites it. It can't act on it.

→ [Custom knowledge](/build-agent/custom-knowledge)

### Author a Skillset

Nothing new needs connecting — the agent already has the tools, it just doesn't
know your procedure. Write it out in plain language as Skills: when to use it,
what steps to take, what to tell the person. If a step needs an API URL or a
credential, add a configuration to the skillset.

This is the exception path. It works, but you own the logic and keeping it
correct.

→ [Skillsets & skills](/build-agent/skillsets-and-skills)

### Contact support

If nothing above fits, your use case probably needs something Cobalt doesn't do
yet. Tell us what you're trying to accomplish — it may already be on the roadmap,
or there may be a route we can walk you through.

## Why the order matters

|                 | App                                 | MCP Server / External Agent                 | Knowledge         | Skillset                   |
| --------------- | ----------------------------------- | ------------------------------------------- | ----------------- | -------------------------- |
| Best for        | Connecting a system Cobalt supports | A tool server or peer agent you already run | Reference content | Logic nothing else can do  |
| Built by        | Cobalt (vendor-maintained)          | The server's owner (you or a vendor)        | You               | You                        |
| Maintenance     | Low                                 | Medium (you own the server)                 | Low               | Higher (you own the logic) |
| Acts in systems | Yes                                 | Yes                                         | No (read-only)    | Yes                        |

Reaching for a Skillset when an App already does the job means you take on
maintenance Cobalt would otherwise carry, and you re-implement guardrails the App
already provides. Drop a level only when the level above genuinely can't do it.

## Then control how tools behave

However a tool was granted, you constrain how it's allowed to act with
[tools, rules & hooks](/build-agent/tools-rules-and-hooks): family rules,
per-tool overrides, and hooks that gate individual calls. Privileged actions are
gated and audited by default.