Tool Catalog
The Tool Catalog lists every tool in your workspace and is where you publish them. Publishing is the switch that makes a tool real — a draft tool is never served to an AI client, no matter how well it's configured.
Find it at Dashboard → Tool Catalog.
Where tools come from
You don't create tools here. They're generated when you upload an OpenAPI spec — one draft tool per operation in the spec. This page is where you review and publish them; Tool Studio is where you edit them.
The list
Each row shows:
| Column | Meaning |
|---|---|
| Tool | Its name — what the AI sees when deciding whether to call it |
| Connection | Which connection it belongs to |
| Method | The HTTP verb of the underlying operation |
| Endpoint | The upstream path it calls |
| Status | Published or Draft |
| Version | Which version is currently active |
| Access | Which roles may call it |
You can search by name, and filter by connection — useful once you're running several.
Publishing
Select one or more tools and click Publish. Unpublish takes them back out of service.
Selection is multi-row, so publishing an entire spec's worth of tools is one action rather than dozens.
| State | Served to AI clients? |
|---|---|
| Draft | No |
| Published | Yes — subject to role access |
Publishing takes effect immediately. Unpublishing does too — it's the fastest way to withdraw a tool that's misbehaving, without touching your API or the connection.
The Access column — the part people miss
Publishing makes a tool available. It doesn't make it visible to your team.
A tool is served to a member only when both are true:
- The tool is Published, and
- A role that member holds has been granted access to it
A published tool with no role access is invisible to everyone except workspace admins. Because admins typically see everything, this reliably produces "it works for me but my team sees no tools".
Set access from the Access column, or in bulk — see Assigning Tool Access.
Versions
Tools are versioned. Re-uploading a spec creates a new version rather than overwriting the live one, so a spec change can't silently alter what AI clients are calling.
The Version column shows what's active. Rolling back is done in Tool Studio.
A sensible publishing workflow
Publishing everything a spec produced is rarely right — most APIs have operations that shouldn't be AI-callable.
- Upload your spec and see what was generated.
- Review the drafts. Decide what genuinely belongs in an AI's hands. Destructive or administrative operations usually don't.
- Refine names and descriptions in Tool Studio. This has more effect on behaviour than anything else you'll do — the description is how the AI decides whether a tool fits the task.
- Publish the ones you want.
- Grant role access so your team can actually see them.
- Test from a real AI client before telling anyone it's ready.
Be deliberate about destructive operations. An AI client that can call delete_customer will eventually call it. Restrict such tools to a narrow role, or leave them unpublished.
Troubleshooting
| Symptom | Cause |
|---|---|
| Tool published but nobody sees it | No role has access. Check the Access column. |
| Admin sees it, members don't | Same cause — admins bypass role-based visibility. |
| Nothing appears after uploading a spec | The spec may have failed to parse. Check API Specs. |
| Tool appears but calls fail | Authentication is fine; the upstream call isn't. Check credentials and the endpoint in Tool Studio. |
| Changes aren't reflected in the AI client | Some clients cache the tool list for a session. Reconnect. |
More in Troubleshooting.
Where to go next
- Tool Studio — editing tools
- Assigning Tool Access — controlling who can call what
- Writing OpenAPI Specs — where tools come from