AI agent tools are the functions, apps, APIs, and data sources an agent can call to do work beyond generating text. The best choice is not the platform with the longest integration list. It is the one that gives the agent the smallest useful action set, clear authorization, inspectable results, and a reliable way to remove access.
Runner AI makes that distinction practical for ecommerce operators. Its Agent Apps catalog lets you inspect an external service’s available tools, turn off actions the Agent should not use for a project, authorize the account separately, and later manage or disconnect the connection. The workflow is conditional by workspace and provider, so the current catalog remains the source of truth.
Key takeaways
- An AI agent platform provides the reasoning loop; an agent tool provides a specific capability such as reading a record, creating an item, or calling an external service.
- Evaluate the action surface, authorization scope, project controls, confirmation boundaries, observability, failure behavior, and revocation path before comparing catalog size.
- Read-only and write-capable tools should not be treated as equivalent merely because they connect to the same app.
- A connected account and a tool enabled for one project can be separate control layers.
- In Runner, review the advertised tools before connecting, disable unnecessary actions, and confirm the saved connection state instead of assuming an authorization window succeeded.
What are AI agent tools?
An AI agent tool is a bounded operation an agent can invoke as part of a task. It may retrieve data, create or update a record, search a service, send content, or trigger another system. In a common model-driven design, the model selects a tool while application code defines and executes it. Other systems select tools through deterministic workflows or direct user actions. Input validation and authorization must be enforced by the application or downstream service; they are not automatic properties of tool use.
That makes a tool different from the other parts of an agent system:
| Component | Primary job | Example decision |
|---|---|---|
| Model | Interprets the request and produces or evaluates language | “The user wants the latest order status.” |
| Instructions | Set the agent’s role, process, and limits | “Do not change an order without explicit approval.” |
| Memory or context | Supplies relevant information from this task or prior work | The store, customer, or policy involved |
| Tool | Performs a defined operation outside the model | Read an order record |
| Workflow | Controls sequence, branches, retries, and approval points | Read first, propose a change, then wait for approval |
This distinction matters when comparing products. A visual agent builder, a developer framework, and a catalog of external integrations may all rank for “AI agent tools,” but they solve different layers. Start with the job you need completed, then identify the minimum external operations required. Do not begin with a large catalog and search for reasons to use it.
The seven checks that matter more than tool count
Integration totals are easy to compare and hard to interpret. One service may expose a single narrow read operation. Another may expose dozens of read, create, edit, send, and delete actions. Both count as one integration, but their usefulness and risk are different.
1. Does the tool match a defined job?
Write the intended task in operational terms: input, action, output, and stopping point. “Help with marketing” is too broad. “Read the approved campaign brief and create a draft record for review” identifies the source, the allowed change, and the boundary before publication.
A tool is useful when its actual operations fit that job. If the job only needs retrieval, a connection that also grants sending or deletion deserves extra scrutiny. If the service cannot expose the one required operation, a long list of adjacent tools does not close the gap.
2. Can you inspect individual actions before connecting?
The app name is not enough. Review action names and descriptions before authorization. Separate read operations from writes, and distinguish reversible changes from actions that contact customers, publish content, move money, delete data, or alter permissions.
OWASP’s 2025 guidance on excessive agency identifies excessive functionality, permissions, and autonomy as separate causes of damaging agent behavior. Its mitigations include minimizing extensions, minimizing their functions and downstream permissions, preferring granular operations over open-ended ones, and requiring approval for high-impact actions. The guidance describes risk categories and mitigations; it does not certify a particular product as safe.
3. Where does authorization live?
Ask whose account is connected, which downstream permissions it carries, and whether access applies to one project, a workspace, or every task run by that user. Also distinguish the provider’s authorization scope from controls inside the agent product. Turning off a tool in one interface does not necessarily change the OAuth scopes or API-key privileges granted by the external provider.
NIST defines least privilege as restricting users, or processes acting for users, to the minimum access needed for assigned tasks. Applied to agent tools, that means limiting both the operations offered to the agent and the privileges of the downstream identity used to execute them.
4. Can access differ by project?
Project-specific controls are valuable when one connected account supports several workflows. A research project may need read access while an operations project may need a bounded write action. Check whether disabling an operation affects only the current project, the whole workspace, or the underlying provider account.
This is also a governance question. Someone reviewing a project should be able to understand which external actions are available there without reconstructing every prior authorization event.
5. What requires confirmation?
Tool access and approval are complementary controls. Disabling unnecessary tools narrows what can happen at all. A confirmation step can then protect a consequential action that remains available.
Use stronger review for actions that are public, financial, destructive, difficult to reverse, or based on uncertain inputs. The article on meaningful human-in-the-loop AI explains how to place review immediately before the consequence and give the reviewer enough evidence and authority to reject it.
6. How does the system fail?
Look beyond the happy path. A useful agent system should distinguish an unavailable integration, expired authorization, rejected credentials, an operation timeout, and an invalid tool result. It should not silently substitute a different action or report success merely because an authorization window closed.
Failure isolation matters when several toolkits are connected. If one provider is unavailable, the product should make the loss visible and avoid treating a failed tool as usable. Whether the rest of the task should continue depends on the task: summarizing available data may continue, while a workflow requiring that missing source should stop.
7. Can you revoke access and verify the result?
Before connecting, find the management and disconnect path. Learn whether disconnection removes one project’s access or the signed-in user’s account-level connection. After disconnecting, verify the visible state. An error or closed dialog is not proof that credentials or provider access were removed.
Revocation is part of the product, not an emergency-only feature. Use it when a provider account changes owners, a project ends, credentials may be exposed, or the tool is no longer required.
A practical AI agent tools scorecard
Use the same test task for each product you evaluate. This prevents a polished demo for one platform from being compared with documentation claims for another.
| Area | Question to test | Strong evidence |
|---|---|---|
| Task fit | Can the tool complete the exact job without unrelated actions? | Named operations match the input and output |
| Action visibility | Can you inspect tool names and descriptions before authorization? | A complete, readable action list |
| Access scope | Who owns the connection and where do controls apply? | User, workspace, and project boundaries are explicit |
| Least privilege | Can unnecessary read or write actions be disabled? | Tool-level controls affect runtime availability |
| Approval | Can consequential actions pause for review? | The reviewer sees the proposed action and consequence |
| State | Does the interface distinguish connecting, connected, failed, and expired access? | Current state is visible after refresh |
| Failure isolation | What happens when one provider fails? | Failure is reported without inventing success |
| Revocation | Can access be removed and confirmed? | Disconnect has a clear scope and verifiable result |
| Portability | Can you export configuration or reproduce the setup? | Documented configuration, API, or export path |
| Cost | What is charged per user, run, tool call, or provider request? | Pricing separates platform and downstream usage |
Score launch-blocking requirements first. A platform that cannot meet a required authorization or approval boundary should not win because it has more integrations or a lower monthly price.
How Runner handles connected AI agent tools
Runner’s implementation is useful because it separates discovery, authorization, project configuration, and runtime use.
Inspect before authorizing
Under Project → Apps → Connect your tools, an operator can search the conditional Agent Apps catalog, open an app, read its description, and inspect its advertised tools. Viewing those details does not connect the external account. The operator can turn off tools the Agent should not use in that project before starting the provider flow.
The available catalog and connection method depend on the current workspace, project, provider, and staged availability. Some apps use an external authorization window; others request provider credentials in the connection dialog. No specific catalog entry should be assumed until it appears in the current workspace.
Keep connection scope and project scope distinct
Runner’s current Agent Apps guide documents an important boundary: the external account connection belongs to the signed-in Runner account, while enabled or disabled tool choices are stored for the current project. This allows projects to expose different action sets, but disconnecting the account-level connection can affect other projects that use it.
At runtime, Runner filters disabled tool slugs out before making the surviving tools available to the Agent. If every tool in a connected toolkit is disabled, that toolkit contributes no tools to the run. The current runtime then caps the combined connected-tool set at 50 tools. It also loads connected toolkits independently, so one provider failing to load does not falsely turn its actions into available tools.
Verify connection and recovery states
Completing a provider page is not the same as Runner confirming a usable connection. Return to Apps and look for Connected. Use Manage to review saved tool switches. If authorization expires or fails, follow the state Runner shows rather than creating another connection blindly.
The connection lifecycle guide covers connect, reconnect, and disconnect states. The troubleshooting guide explains how to handle blocked authorization windows, tool-list failures, unsaved switches, rejected credentials, and uncertain disconnects without exposing secrets.
A safe first connection workflow
Use a low-consequence task to test both capability and control.
- Define one task. Name the record to read or draft to create, the source of truth, and where the process must stop.
- Choose the external service. Confirm that it contains the required data or action.
- Inspect every advertised tool. Separate reads, writes, sends, deletes, and permission changes.
- Disable unrelated actions. Keep only the operations needed for the test project.
- Authorize deliberately. Check the provider account and requested scope before approving or entering credentials.
- Confirm the saved state. Return to the product and verify that the connection is actually marked connected.
- Run representative tests. Include a normal request, an ambiguous request, a request outside scope, and a provider failure when possible.
- Inspect the result in the source system. Do not rely only on the agent’s summary.
- Test management and revocation. Change one tool setting, verify it saved, then document the disconnect path before production use.
If the workflow itself repeats, distinguish tools from reusable instructions. A tool supplies the external operation; a custom AI Skill packages a stable procedure for deciding how to use available context and tools. Memory is another layer: agent memory retains selected information, not permission to act in an external system.
AI agent tools FAQ
What tools do AI agents use?
AI agents can use search, databases, files, browsers, code execution, communication services, commerce systems, project-management apps, and custom APIs. The useful set depends on the task. Evaluate the individual operations and authorization boundary rather than assuming every tool in a category is interchangeable.
Are AI agent tools the same as AI agent builders?
No. A builder or framework provides the environment for defining and running an agent. A tool is a callable capability supplied to that agent. Some products bundle both, which is why search results often mix builders, automation platforms, frameworks, and integration catalogs.
Should an agent receive every available tool?
Usually not. Give it the smallest set needed for the intended task. Extra tools enlarge the action surface, complicate selection, and can increase the effect of an ambiguous request or compromised input. Also limit the downstream provider account to the minimum practical permissions, and retest the workflow whenever its required tools or provider access changes.
Is OAuth enough to make an agent integration safe?
No. OAuth can establish delegated access, but safety still depends on the scopes granted, the operations exposed to the agent, runtime authorization, approval boundaries, input and output handling, monitoring, and revocation. OAuth 2.0 defines scope as a way for the client to request a level of access and for the authorization server to grant that scope in whole or in part. Tool-level controls inside an agent product do not automatically reduce the scopes already granted at the provider.
What is the difference between disabling a tool and disconnecting an app?
Disabling a tool removes a specific operation from the agent’s available action set within the relevant product scope, while leaving the underlying account connection in place. Disconnecting removes that account connection. In Runner, tool choices are project-specific, while the Agent App connection belongs to the signed-in account. A project-level switch and an account-level disconnect therefore have deliberately different effects.
Evaluate the action surface, not the catalog headline
Choose one real task and write down the minimum reads and writes it requires. During evaluation, verify those operations, disable everything else, complete authorization, test an out-of-scope request, and prove that you can revoke access. That exercise reveals more than a catalog total or polished demo.
To apply the checklist in Runner, open the Agent Apps workflow, inspect a currently available app, and leave unnecessary tools disabled before connecting it to a low-risk project.
Sources
- OWASP Gen AI Security Project, “LLM06 Excessive Agency”, 2025; retrieved September 16, 2026.
- National Institute of Standards and Technology, “least privilege”, citing CNSSI 4009-2022 and NIST SP 800-53 Rev. 5; retrieved September 16, 2026.
- Internet Engineering Task Force, RFC 6749, “The OAuth 2.0 Authorization Framework,” section 3.3, October 2012; retrieved September 16, 2026.