> This page is for Tools. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.moveworks.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server. # Debug a Plugin When a plugin returns an error or the wrong result, attach it to a ToolSmith chat and describe the problem. ToolSmith reads the plugin's execution logs, names the likely cause, and proposes a fix as a plan. Nothing changes until you approve the plan. ToolSmith can debug any plugin, including one built by hand in Tool Studio. It does not watch for failures, so start a chat when you or a user finds one. The examples on this page come from a plugin that lists open ServiceNow incidents, broken on purpose by changing one action's table name to one that does not exist. ServiceNow rejects the request with HTTP 400, so the plugin fails when an employee asks, "Show my open incidents." # Problems ToolSmith can investigate Describe the problem as you see it. You do not need to know the cause. | What you see | What to include | Learn more | | --------------------------------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | An HTTP error status, such as 400, 401, 403, or 404 | The status and error message | [What each status means](/tool-studio/guides/getting-started/testing-and-error-handling#http-action-errors), [HTTP Action Troubleshooting](/tool-studio/actions/http-actions/http-action-troubleshooting) | | A data mapping or DSL error | The exact error message | [DSL](/api-reference/configuration-languages/dsl), [Data Mapper Reference](/api-reference/configuration-languages/moveworks-bender-language-reference) | | A slot validation error | The user's value and the error message | [Slot Validation Policy](/tool-studio/conversation-process/slots#slot-validation-policy) | | Empty or wrong results | What the plugin returned and what the external system holds | [Debugging with logs](/tool-studio/guides/getting-started/testing-and-error-handling#debugging-with-logs) | # Find and fix the cause > **Warning** > > ToolSmith publishes the assets it changes, so a fix reaches everyone who uses the plugin before you test it. When you can, debug in a non-production environment, then move the plugin to production with [Plugin Promotion](/tool-studio/development-and-testing/managing-plugins/plugin-promotion). #### Attach the plugin to a new chat Start a new ToolSmith chat, select **+** in the message box, and search for the plugin in the **Search plugins…** box. You can attach plugins only, so if you suspect an action, attach a plugin that uses it. #### Describe the problem A short report works, such as "This plugin is broken. Figure out why and fix it." You can also paste a user's report as they sent it. Details that help: * The exact request that failed * What the plugin answered * What you expected, or what the external system holds * The exact error message The example uses this report: ```text This plugin stopped working. When I ask the assistant "Show my open incidents," it says "I couldn't retrieve your open ServiceNow incidents because the incident lookup failed." I have three open P1 and P2 incidents in ServiceNow. Find out why and fix it. ``` #### Check the cause and the plan Check that the cause matches what you saw, such as the error message or the missing records. If it does not, select **Modify plan** and say what does not fit. In the example, ToolSmith found that "The incident action was changed from the valid table path /api/now/table/incident to /api/now/table/incidents." Its plan changed only that action's path. Then [check the plan](/tool-studio/toolsmith/review-and-approve-plans#check-the-plan-before-you-approve) as you would for a build, including any steps tagged **External action**, which run when you approve. If the fix changes an asset that other plugins use, test those plugins too. In Tool Studio, the asset's more actions menu (⋮) has **Related assets**, which lists them under **Parent Assets**. #### Approve the fix Select **Approve plan**, or **Approve** when the plan has no external actions. ToolSmith applies the fix and reports how many assets it modified, such as "Modified 1 asset". To see which ones, select **Assets** in the Artifacts panel. #### Test the plugin again In the assistant, repeat the request that failed and check the answer. > **Tip** > > If the plugin creates or updates records, also check them in the external system. The reply alone might not show whether a write happened, or happened twice. # If the problem remains If the plugin still fails, tell ToolSmith in the same chat, with the request you repeated, the answer, and any new error message. If ToolSmith cannot fix it, check the plugin's [logs](/tool-studio/agent-telemetry/logs) and [Common Errors](/tool-studio/development-and-testing/common-errors), and [edit the plugin](/tool-studio/development-and-testing/managing-plugins#edit-a-plugin) in Tool Studio. To roll back a fix, see [Undo a change](/tool-studio/toolsmith/modify-a-plugin#undo-a-change). # Related documentation #### [Review and approve plans](/tool-studio/toolsmith/review-and-approve-plans) Check what a fix plan will do, revise it, and approve it. #### [Modify a plugin](/tool-studio/toolsmith/modify-a-plugin) Change a plugin you already have, or ask how it works. #### [Testing and error handling](/tool-studio/guides/getting-started/testing-and-error-handling) Test plugins in the assistant and look up what HTTP error statuses mean. #### [Logs](/tool-studio/agent-telemetry/logs) Troubleshoot a plugin with its logs.