Tools

Give an Agent built-in, connected, or application-executed tools.

Tools let an Agent take action. Checkfu supports three paths, based on where the operation runs and who owns its credential.

Tool path	Runs in	Best for
Built-in tool	The harness sandbox	Files, shell commands, and capabilities the harness already provides
Connected tool	Checkfu’s CapabilityGateway	Provider APIs such as GitHub, Slack, or an MCP server
Custom tool	Your application	Product logic and private operations your own code should execute

These paths share the Agent’s tool-calling interface, but they do not share an execution or credential boundary.

Built-in tools

agent_toolset scopes tools the harness already knows how to run. No Connection or ToolSource is involved.

{
  "agent_toolset": {
    "default_enabled": true,
    "configs": [
      { "name": "bash", "enabled": false }
    ]
  }
}

Use this to narrow a harness, not to grant new provider access. The exact set varies by HarnessProfile.

Connected tools

A connected tool crosses Checkfu’s gateway. Three resources keep the concerns separate:

1. A Connection authorizes one provider account. Its credential stays in the selected custody boundary and is never returned to the Agent, harness, or sandbox.
2. A ToolSource discovers callable operations and their input schemas.
3. The Agent references selected tools by catalog name.

{
  "tools": [
    { "kind": "catalog", "name": "github.create_issue" }
  ]
}

Each ToolInvocation is checked against the Session’s admitted Agent release, the acting Principal’s PermissionAssignments, ActionPolicies, the Connection’s allowed account, and its egress rules. A policy can deny the ToolInvocation or require an ActionApproval before the CapabilityGateway executes it.

Connect a provider account

Authorize an account, wait for the Connection to become healthy, and discover its tools.

Custom tools

A Custom tool is declared inline, but your application executes it:

{
  "tools": [
    {
      "kind": "custom",
      "name": "lookup_order",
      "description": "Look up an order by ID.",
      "input_schema": {
        "type": "object",
        "properties": {
          "order_id": { "type": "string" }
        },
        "required": ["order_id"]
      }
    }
  ]
}

When the Agent calls it, Checkfu appends agent.tool_use and parks the Run. Your application reads the call, executes it, and sends user.custom_tool_result to continue the same Session. Checkfu makes no outbound provider request and holds no credential for this path.

Serve tools from your app

Define, sync, and execute a Custom tool with the TypeScript SDK.

Which path should I use?

• Use a built-in tool when the harness already owns the operation.
• Use a connected tool when Checkfu should govern the provider account and enforce account, approval, and egress policy, attaching the credential only at the trusted outbound edge.
• Use a Custom tool when the operation belongs to your application’s code or network boundary.

An Agent can use all three at once.

Skills

A Skill is not a tool. It is versioned instructions and optional files that the Agent reads inside its sandbox. Skills have no input schema, transport, or approval flow because nothing is being called.

release-notes/
  SKILL.md
  examples.md

Session admission pins the Skill version and content digest, so later edits do not change an existing Session. A SkillSource can sync Skills from a Git Project; ship a self-authored Skill covers the review and verification path.

Advanced connections and catalogs

The Connections and catalog page covers provider packages, OAuth and API-key custody, egress rules, source synchronization, catalog search, enablement defaults, Skills, and proposals. You only need that detail when you are building or governing an integration.