Tools and actions: giving an agent the ability to act | Cleon

An agent that can only read is a search box with better manners. The moment it can act — update a record, send a message, move money — it becomes something you have to govern. This page is about that capability: how an agent acts at all (tool calling), how to design the tools so a confused model can't do real damage, and the two surfaces Cleon composes to give an agent hands — Agentforce Actions inside Salesforce, and MCP as the open protocol that lets a tool travel between systems.

These are complementary instruments, not rival camps. An agent built on Agentforce, one wired together over MCP, and one calling tools directly through the Claude API all share the same underlying mechanic and the same discipline. The skill is composing them for the job, not pledging loyalty to one.

Tool calling: the mechanic underneath

Every way an agent acts reduces to the same loop. You expose a set of tools. Each tool has a name, a description, and a typed argument schema. You hand those definitions to the model alongside the user's request. The model — when it decides an action is warranted — replies not with prose but with a structured call: this tool, these arguments. Your code receives that call, validates it, executes the real work, and returns the result. The model reads the result and continues.

The part that matters, and the part most teams get wrong: the name, description, and schema are the entire interface the model reasons over. The model does not see your implementation. It sees the words you wrote describing what the tool does and the shape of the arguments it accepts. A vague description — "updates the account" — gives the model nothing to reason with, and it will call the tool in situations you never intended or fill an argument with a plausible guess. A precise description — what the tool does, when to use it, when not to, what each argument means — is the difference between a tool the model uses correctly and one it abuses.

A tool definition is data. If you show one, keep it in a fenced block so the angle brackets in any types stay out of the prose:

{
  "name": "update_case_status",
  "description": "Set the Status of ONE support case the user is currently viewing. Use only when the user explicitly asks to change status. Does not create cases, does not close cases owned by another agent.",
  "input_schema": {
    "type": "object",
    "properties": {
      "case_id": { "type": "string", "description": "The 18-char record Id of the case to update." },
      "status": { "type": "string", "enum": ["New", "Working", "Escalated", "Closed"], "description": "The new status." }
    },
    "required": ["case_id", "status"]
  }
}

Notice how much work the schema does. The enum means the model cannot invent a status that does not exist. The description scopes the tool to one case, explicitly requested, and rules out two adjacent actions. You are not trusting the model to behave — you are writing an interface narrow enough that the wrong call is hard to express.

Designing safe tools

Tool calling is also where principle 5 lands: every tool an agent can call is a blast radius. The model will, eventually, pick the wrong tool or fill the right one with a bad argument. Safe design assumes that and contains it. Four rules carry most of the weight.

Least privilege. Give each tool the narrowest scope that still does the job. A tool that needs to update one field should not be able to delete the record. A tool that messages the current contact should not be able to message anyone. Scope it at the tool boundary, in code and in the platform's permission model — not in the prompt, where it is a polite request the model can ignore.
Validate every argument before you execute. The model can pass a malformed value, an Id that does not exist, or a number outside any sane range. Check the call against the schema and against your own business rules before the real work runs. When validation fails, decide deliberately what happens — retry, ask the user, or stop — and never let an unvalidated argument reach the action.
Idempotency where you can get it. Agents retry. Loops re-enter. A tool that is safe to call twice — keyed so a repeat is a no-op rather than a second charge or a duplicate record — turns a whole class of retry bugs into nothing. Not every action can be idempotent, but the ones that move money or send messages benefit the most.
A kill switch and an approval gate on anything consequential. Reads are recoverable; sends, charges, and deletes are not. Consequential actions need a human approval step before they fire and an operator control that can halt a running agent now. These are not the model's job to enforce — they live in your code and your platform, outside anything the model can talk its way around.

Agentforce Actions: acting inside the platform

Agentforce is the Salesforce-native way an agent acts, and its strength is exactly what the section above is about: the action runs inside the platform security model you already have. An Agentforce Action is the tool definition — a name, a description the model reasons over, and typed inputs and outputs — wired to one of a few execution types:

Flow actions — an autolaunched Flow runs the work declaratively. Good when the logic already lives in a Flow or is simple enough to build as one.
Apex actions — an invocable Apex method runs the work in code. Good when you need logic a Flow can't express cleanly, or you already have the method.
Prompt Template actions — the action calls a grounded prompt template, generating text against Data 360 or other Salesforce data through the platform's own grounding.

What you get for staying on-platform is the governance and audit baked in: the action executes as a user under that user's permissions, sharing rules and field-level security still apply, and the platform records what ran. The least-privilege and audit-trail discipline above is partly enforced by the platform instead of hand-built. That is one complementary instrument — the right one when the work lives in the Salesforce security model and needs governed, auditable actions on customer data. See Agentforce agents for how the agent around these actions is assembled.

MCP: one protocol, many hosts

The Model Context Protocol (MCP) is an open standard for connecting models to tools and data sources across systems. Where tool calling is the mechanic an individual model uses, MCP is the protocol that lets a tool — and the data behind it — be exposed once and reused by any host that speaks it. You write an MCP server that exposes a tool (with the same name, description, and schema discipline as any other tool); any MCP-capable host can then discover and call it.

The reason a shared protocol matters is the same reason any standard matters: it kills the N-times-M integration problem. Without it, every tool gets re-implemented for every agent framework that wants it — the same "look up an order" tool written once for one host, again for another, again for a third. With MCP, you write that tool once behind the protocol and every compliant host reuses it. The tool and the agent stop being welded together; you can change the host without rewriting the tools, and add a tool without touching the host.

For Cleon that makes MCP the connective tissue when an agent needs tools that span systems Salesforce does not reach, or when you want the same governed tool callable from more than one place. It is complementary to Agentforce Actions, not a replacement: Agentforce Actions are how an agent acts inside the platform; MCP is how tools interoperate across hosts. The same safe-tool rules — least privilege, validation, idempotency, gates on consequential actions — apply to an MCP-exposed tool exactly as they do to any other, because on the far side of the protocol it is still real code taking a real action.

The discipline, restated

The mechanic is simple and the surfaces differ, but the rule under all of them is one sentence: a tool that can delete, send, or charge needs an approval gate, a blast-radius limit, and an audit trail. Tool calling gives an agent reach; that reach is the whole risk. Whether the action runs as an Agentforce Flow, an Apex method, or an MCP-exposed function, the question to answer before you ship is the same — what is the worst this tool can do, who approves it when it is consequential, and can someone stop it and reconstruct it afterward. Get that right and the rest of the design is detail. Get it wrong and "the agent did it" becomes an incident with no owner. (See agent gotchas for the other ways this goes wrong in production, and the Agent Style Guide for the bar an agent clears before it ships.)

What is an agent — the anatomy before the actions
Orchestration patterns — where in the loop a tool call happens, and how to bound it
Agentforce agents — assembling the agent around Agentforce Actions
Agent gotchas — hallucinated calls, over-broad tools, and missing gates
Agent Style Guide — the bar an agent clears before it ships
Data 360 agent-readiness check — the grounding side of a safe agent
Marketing Cloud AI Style Guide — which AI surface for which job

Reference: