Tool Pages in XTM One
This page complements Tools in XTM One.
That guide explains what tools are for. This page explains what the Tools pages show and how they work in XTM One.
What you see in the sidebar
In the left navigation, this area appears as Tools.
The page title is also Tools.
What the list page looks like in XTM One
In XTM One, the main visible section is Built-in Tools.
Those cards represent platform-provided capabilities such as:
- Image Generation
- Code Interpreter
- Web Fetch
- Browser
- XTM One
That means the Tools page is often less about configuration and more about understanding what the platform already makes available to agents.
Each built-in tool card shows:
- tool name
- short description
EnabledCompany-managedBuilt-in- a short tag such as
image,code,web,browser, orplatform
Those card signals help you answer simple but important questions:
- is this a standard platform capability or a local customization
- is the tool active in the environment
- what category of action does this tool add to agents
In some platform variants outside the standard XTM One experience, the same area can also expose Custom Tools. When that happens, the page gains search, visibility filters, tag filters, and an Add Tool action.
What built-in tool detail pages look like
Opening a built-in tool leads to a dedicated detail page with:
- back button to
Tools - built-in badge
- enabled badge
- company-managed badge
- tabs
The built-in tool detail page is organized into:
OverviewConfigurationActivity
Built-in tool overview tab
The Overview tab shows:
- how many agents use the tool
- how many assignment runs used it
- last activity
- the fact that the tool is built-in
This gives you a quick sense of whether the tool is only available in theory or already used in real workflows.
It also includes:
- a description card
- current image model for
Image Generation - an
Agents Using This Toolpanel
This is the easiest place to answer:
- what the tool actually does
- whether anyone is using it
- whether it has been used recently
Built-in tool configuration tab
The Configuration tab is usually informational for built-in tools.
For Image Generation, the configuration area can also expose the current model selection. In practice:
- admins can change the platform-wide image model
- non-admins can see the current model but not change it
That means the UX can differ depending on role even when the page itself is visible to everyone.
Built-in tool activity tab
The Activity tab shows runs linked to agents using that built-in tool.
Open this tab when you want to understand whether a tool was used in recent workflows.
Custom tools in some deployments
Some deployments can also show custom tools. When they do, the list page includes:
- search
- visibility filter
- tag filter
Add Tool
In that mode, the Tools area behaves more like the other resource libraries, because users can both inspect built-in capabilities and manage organization-specific actions.
Custom tool cards show:
- tool name
- description
- enabled or disabled state
- language
- timeout
- parameter count
- tags
Those fields are especially helpful when comparing two similar tools, because they show whether the tool is lightweight or more complex and whether it expects structured inputs.
Custom tool detail pages
When custom tools are available, their detail page contains:
OverviewConfigurationActivity
The header also includes:
Test Tool- delete
The Overview tab shows:
- description
- language
- execution timeout
- input parameters
- tags
- timestamps
- agents using the tool
The Configuration tab can expose:
- name
- icon URL
- description
- input parameters
- code editor area
- language switch between JavaScript and Python
- execution timeout
Hide from chat- sharing settings
The most meaningful distinction on this screen is:
- parameters define what the tool expects
- code defines what the tool does
- timeout defines how long the platform will wait
- visibility settings define who can discover and reuse it
Test Tool opens a dedicated test dialog. From a UX perspective, that is the fastest way to validate whether a custom tool works before binding it to an agent.
Read-only expectations in XTM One
A practical expectation to set is this:
- built-in tools are part of the platform
- they are visible and understandable
- they are not treated like personal resources
So the main experience is usually inspection and understanding rather than ownership and creation.
Good habits on these pages
- Use the tool description to understand capability before attaching it to an agent.
- Check
Agents Usingbefore changing shared tool settings. - Treat
Image Generationconfiguration as platform-wide, not per-agent. - In standard XTM One mode, expect built-in tools to be the main visible UX.