Resources & Tools

Resources

A resource is an MCP server the platform can call — an API surface with a base URL and an optional path (typically /mcp).

Registering a resource (Resources → Create Resource, or POST /api/resources, permission create-resource) does more than store a URL:

• Agentfleet registers the resource with the identity provider as an API resource and binds its audience. Every token issued for this resource is audience-restricted to it — a token minted for one resource cannot be replayed against another.
• The platform's client is granted access so it can discover the resource's tools.

Resource settings

Setting	Endpoint	Effect
Name, description, base URL, path	PUT /api/resources	Where the MCP server lives.
DPoP requirement	PUT /api/resources/dpop-requirement { resourceId, requiresDpop }	The resource only accepts DPoP-bound tokens. Every exchange for it asks for a token bound to the step's ephemeral key, a plain bearer token in reply is refused, and every call carries a fresh proof. Off by default. API only.
Sensitivity labels	PUT /api/resources/sensitivity-labels { resourceId, labels }	Labels such as pii describing what the resource's tools return. A model may only be offered those tools if its allowlist covers every label. See Usage & Data Governance.

All of these need update-resource.

Lifecycle

Resources are Active, Inactive, or Deleted. Tools can only be imported from an active resource, and steps can only run against active resources.

Tools

A tool is a callable operation on a resource — its name, description, JSON parameter schema, and OAuth scope. Tools are usually imported from the MCP server's own advertisement, and can also be registered one by one (POST /api/tools). Tools are Active, Inactive or Deleted, like resources.

Importing

Use Import Tools on a resource (POST /api/resources/{id}/import-tools, permission import-mcp-tools). Discovery is idempotent:

• New tools are registered.
• Already-registered tools (matched by name) have their description, schema and scope refreshed.

Re-import whenever the upstream server changes its tool surface.

Per-caller tool filtering

Discovery calls tools/list as Agentfleet's own client (a client-credentials token audienced for the resource), not as you. MCP servers that filter listings per caller therefore show the tools that client may see. A missing tool after import usually means the platform client lacks access to it on that server, not that the tool doesn't exist: grant the access on the MCP server side, or register the tool individually.

A resource that requires DPoP cannot be imported from (discovery presents a bearer token, which such a resource refuses); register its tools individually instead.

Scopes drive least privilege

The tool's scope is not documentation — it is enforced. When a step runs, it exchanges a token per resource, on first use, asking for exactly the scopes of the step's own tools on that resource. The identity provider intersects the request with what the user and the agent are each allowed, so a step can never widen its own access. If a tool imports without a scope (or with a wrong one), correct it on the tool before using it in a step.

Tools on steps, and confirmation

A step has an ordered tool allowlist (Add tool on the step page, or POST/PUT /api/steps/tools). Each tool on it has a confirmation mode:

Mode	When the model calls the tool
Auto (default)	The call runs at once. Right for read-only tools.
RequiresConfirmation	The run pauses with the proposed call until a person approves it (optionally editing the arguments) or rejects it. A rejected call never runs.

The mode belongs to the tool's place on a step, not to the tool, so the same tool can be automatic in one step and need confirmation in another. A deterministic step's tools cannot require confirmation. In an assistant profile, each tool requires confirmation by default. See Tool calls that need confirmation.

Built-in tools

Besides the tools on its allowlist, a model may be offered platform built-ins. They call no resource and need no delegated token.

Built-in	Offered	What it does
read_result	Every model step and chat turn	Reads a slice of a large tool result by its reference handle.
search_result	Every model step and chat turn	Ranks a large result's chunks against a query (semantically, when an embedding model is configured).
summarize_result	Every model step and chat turn	Summarizes a large result with a model.
read_context	Every model step and chat turn	Reads a context value too large to show in full in the prompt.
load_skill	When on-demand skills are attached	Reads one of the attached skills.
request_clarification	Steps that allow clarification	Pauses the run to ask a person a question.
read_run	Chat turns	Reads one of the user's runs.

An Orchestrator agent's workflow tools are offered alongside these. See Large results for how result references work.

Related

• Steps & Workflows — binding tools into executable steps.
• Identity & Security — how scope and audience shape the issued token.
• Runs — what a tool call that waits for confirmation looks like.