ServiceNow AI Agent Toolkits: choose the tools your job needs

The actual ServiceNow tool types

The current ServiceNow Skill Kit reference describes tools as utilities that run before a skill prompt, gather data, call services, or run scripts. A tool node can run:

These are Skill Kit tool nodes, not a promise that every row is directly selectable as an AI Agent Studio tool. Within a skill, ServiceNow lets tools run sequentially, in parallel, or through conditional decision branches. Confirm the relevant Studio or Skill Kit configuration before designing around a type. That flexibility is useful only after the job is narrow enough to explain.

Build a toolkit around an order-status job

Imagine a customer asks, “Where is my order?” A useful agent should not be given generic access to every customer, order, and refund record. It needs a specific set:

1. Identity and order-evidence check. Does the request include the information your policy requires before an order lookup?
2. Order-status lookup. Retrieve only the status, shipment information, and exception fields the answer needs.
3. Policy retriever. Get the current delivery and escalation policy as context.
4. Response or handoff. Explain the status if the evidence is sufficient; route to a human if the account cannot be established, the order is an exception, or the result conflicts with the request.

This is a toolkit in the useful sense: a short list of capabilities with names, inputs, and boundaries. It is not an invitation to add every tool available.

Tool descriptions are operating instructions

ServiceNow's prompting guide explains that a tool's description tells an AI agent when and why to use it, including how it should use inputs and outputs. Name the tool for the job. “Get verified order status” tells an agent more than “Tool 1.” State when it should not run as well: “Do not use unless an order reference and approved account evidence are present.”

The description is not a replacement for permission design. It helps the agent choose; the security boundary must still prevent it from seeing or changing what it should not.

Separate invocation from data authority

ServiceNow's AI Agent Studio guide distinguishes two controls:

• ACLs decide which users can discover and invoke an agent or workflow.
• User identity decides what the agent can access once it runs.

Dynamic-user identity, which ServiceNow recommends as the default, inherits the invoking user's roles. An AI user is a dedicated account with fixed roles and is for cases that need access beyond those invoking roles. Role masking can further limit inherited roles. For script tools, use GlideRecordSecure rather than GlideRecord when reading platform data so table-level ACL checks are enforced.

An ACL that allows a user to start an agent does not, by itself, authorise every record operation the agent may attempt.

Test a custom API before you ask an agent to rely on it

If an order-status system is outside ServiceNow, test the connection as an interface, not as an optimistic demo. Use a valid order, an invalid order, a request with missing account evidence, an expired credential, a slow or failed response, and an unexpected field shape. Record what the tool returns and what the agent does next. The correct response to missing evidence may be a targeted question or a human handoff, not another lookup.

For a support team using eesel, the same teammate and workspace are available in the dashboard, terminal, scripts, Claude Code, Codex, and Cursor. With Node.js 18.17 or newer, an operator can inspect a custom order-status connection before approving a configuration update:

npx @eesel/cli integrations api check --agent "Customer support"
npx @eesel/cli instructions --agent "Customer support"
npx @eesel/cli approvals --agent "Customer support"

The first command checks custom API access. The second confirms the teammate's standing rule for missing account evidence. The third reveals held actions waiting for a human decision. Use --dry-run for a supported write after you have checked the expected request, not as a substitute for testing the API result. The CLI does not configure ServiceNow; it is another way to operate and review the eesel teammate in the same workspace. See the eesel CLI documentation for the supported commands.

The eesel integrations page shows the connections a teammate can use.

Keep the toolkit small enough to own

Every tool should map to one support outcome, one data boundary, and one observable test. Add a tool only when a real failed case shows the current set cannot do the job. That approach produces a smaller system, clearer access reviews, and a better explanation when someone asks why an agent acted.

Test one support action before adding another

eesel is a ready-to-work AI helpdesk teammate, not a ServiceNow configuration layer. It can help a support team inspect the knowledge, rules, API access, activity, and approvals behind one bounded job from the dashboard or CLI. Try eesel when you want to test that job before widening its scope.