Overview

ToolSmith is an assistant in Tool Studio that builds, changes, and debugs plugins. You describe the result you want, the systems it touches, and who will use it. ToolSmith proposes a plan, and once you approve it, it builds the plugin. You do not need to know the system’s API or how Tool Studio assets fit together.

ToolSmith also works on plugins you already have. Reference a plugin to change it, ask how it works, or find out why it fails. Every change goes through a plan that you approve first.

What you can do with ToolSmith

How a build works

You can leave the chat and come back later. ToolSmith keeps working until it needs something from you, such as an approval or credentials.

What ToolSmith uses

• The Action Catalog. A library of third-party API documentation that ToolSmith checks first. When it needs more, it researches the vendor’s public API documentation. You can also give it an API schema in the chat.
• Your existing assets. ToolSmith reuses suitable assets you already have, especially connectors. See Reused and new assets.
• Moveworks documentation. ToolSmith follows Moveworks documentation and plugin-building best practices.
• Execution logs. When you ask ToolSmith to debug a plugin, it reads the plugin’s execution logs.

Before you begin

Before using ToolSmith:

• Make sure ToolSmith is enabled for your organization. You open it from Tool Studio.
• Start with a focused workflow involving one or two systems.
• Use a test or non-production environment. While it builds and tests a plugin, ToolSmith calls external endpoints, and some of those calls can send data to or change data in a connected system. To move a finished plugin to production, see Plugin Promotion.

Write effective prompts

ToolSmith works out the API calls and the Tool Studio assets. Your prompt describes the result: what the plugin does, who uses it, and how it behaves. ToolSmith builds with what your prompt gives it and asks you questions when it needs to resolve something ambiguous.

A good prompt covers:

• The outcome and the users. What the plugin does, and who uses it.
• The systems. Each system the plugin reads from or changes, and any existing plugin, action, or connector to use or leave unchanged.
• The rules. Conditions, filters, confirmations, and exceptions.
• The results. The fields to show, and what to do when nothing matches, the input is invalid, or the system returns an error.
• The limits. What ToolSmith must not change, and what is out of scope.

For example:

Build a plugin that shows employees their open ServiceNow incidents, highest priority first. Find the employee's ServiceNow user by the email of the person asking. For each incident, show the number, short description, priority, and state. Leave out resolved and closed incidents. If they have no open incidents, say so.

Configure credentials securely

When a new connector needs credentials, ToolSmith pauses and shows a Credentials needed card. Select Configure… to open the Complete Configuration form, check the connector details ToolSmith filled in, enter the secret values, and select Save & Resume.

Enter credentials in this form, not in the chat. ToolSmith asks for each new connector’s credentials in turn, and does not ask when it reuses a connector you already have.

Limitations and considerations

Limitations

• ToolSmith cannot delete assets. Delete assets directly in Tool Studio when needed.
• ToolSmith conversations cannot be shared with other users.

Considerations

• Results vary by system and workflow complexity. ToolSmith’s output depends on the available API documentation, your existing assets, and your prompt, and the same prompt can produce a different plan. If a plan does not meet your requirements, add rules, inputs, outputs, examples, or constraints, as described in Write effective prompts. You might still need to finish part of the work by hand.
• A finished build can still fail. Test every plugin with representative requests. If it fails, ask ToolSmith to debug it.
• Tests can affect connected systems. Approving a plan also approves the external actions it lists. Use a test or non-production environment, and review the expected side effects before you approve.

You remain responsible for reviewing and testing the result. Confirm that the plugin behaves as expected across representative scenarios and edge cases, and that it matches the approved plan, before you publish it more widely or use it in production.

FAQs

Do I still need to configure connectors and access control?

Yes. ToolSmith builds the plugin; you own the connection credentials, permissions, and testing, exactly as with a hand-built plugin.

Can I paste credentials into the ToolSmith conversation?

You can, but we strongly advise against it. Enter credentials, API keys, tokens, and other secrets in the secure configuration form instead.

Which systems can ToolSmith build actions for?

Any system with an API. If the system’s API documentation is not public, give ToolSmith the API schema in the chat. Systems in the Action Catalog are faster and more reliable because ToolSmith already has their documentation. To check coverage, select ToolSmith optimized under the ToolSmith filter on the AI Agent Marketplace Explore page.

Can ToolSmith change or debug plugins it did not build?

Yes. ToolSmith can change and debug any plugin, including plugins built by hand in Tool Studio. See Modify a plugin and Debug a plugin.

Does ToolSmith install Marketplace templates?

No. ToolSmith builds from scratch and reuses your existing assets where it can. To install a template, use the AI Agent Marketplace.

Where do I use ToolSmith?

In Tool Studio, once ToolSmith is enabled for your organization. ToolSmith is in controlled availability; register interest on the Marketplace ToolSmith page.

Related documentation