Tool Packs

Tool description overrides

Rewrite a tool's description so an employee's AI picks it correctly

A tool’s description is what a model uses to decide whether to call it. The defaults Merge ships are good starting points, but they are written for the provider’s API as it was named upstream. Your “ticket” might be their “issue,” your “deal” might be their “opportunity,” your “customer” might be their “account.” An employee asking their AI to “file a ticket” is easier to serve when the tool says ticket.

Description overrides let you rewrite the description a model sees. They are a small change with outsized effect on which tool gets called.

When to override

The default description is fine for most tools. Reach for an override when:

  • The model picks the wrong tool. Two tools have similar default descriptions and the model keeps confusing them.
  • Your organization has different terms. Your team lives in “opportunities” but the Connector exposes them as “deals.” Rewriting the description in your term makes the model more likely to call the right thing.
  • You want to constrain behavior. “Use this tool only for high-priority tickets” steers the model without code.
  • The default description is too long. Some defaults pull verbatim from provider API docs and bloat the system prompt. Trimming saves tokens.

If the description is fine and the problem is that employees’ AI has too many tools to choose from, the fix is a smaller Tool Pack, not an override.

Override from the dashboard

Open the Connector from Connectors, stay on its Overview tab, and pick the tool from the list. The editor shows the tool’s current description and lets you replace it, with the default kept so you can revert.

Save and the override applies on the next tools/list call.

Where overrides apply

An override is set per Connector and tool, and it applies organization-wide. Every Tool Pack that exposes that tool shows the description you wrote, so there is one answer to “what does this tool say” rather than one per pack.

Overrides do not change the tool’s input schema or its behavior. The provider’s API is still called the same way; only what the model reads changes. To change what the model can send, see Tool input overrides.

What “good” overrides look like

  • Lead with the verb. “Create a Slack message in a channel,” not “This tool can be used to create a Slack message in a channel.”
  • Use your term. If your team says “ticket,” put “ticket” in the description even when the Connector is for Jira, where the term is “issue.”
  • Add a usage hint when it disambiguates. “Use this only for tickets in the support project.” Hints matter when two tools could both apply.
  • Keep it short. One sentence usually beats a paragraph.

Test the override by asking for something the tool should handle. If the right tool fires, the description works. If not, refine it and try again. The Playground is the tightest loop for this.

Next

Constrain what the model can send with Tool input overrides.