BuildTools

Tool Input Overrides

Hide, constrain, or set defaults on a tool's input schema.

Tool Description Overrides change what the model reads. Tool Input Overrides change what the model can produce. Where description overrides shape selection (“which tool to call”), input overrides shape the call (“what arguments to pass”).

Input overrides edit the JSON schema the model sees for a tool. Common moves:

  • Hide a field the model shouldn’t think about - pagination cursors, internal IDs, debug flags.
  • Force a field to a specific value - every call goes to a fixed project, channel, or workspace.
  • Set a default so the model can omit a field but the tool still gets a value.
  • Narrow an enum - restrict an open-ended type field to the three values you support.
  • Relabel a field so the model uses your term instead of the third party’s.

All of these can be done via the dashboard or the API. Overrides are scoped per Tool Pack.

When to use them

Forcing a fixed value

You’re building an agent for one Slack workspace, and you don’t want the model to ever pick which workspace a message goes to. Override the workspace_id field on slack__post_message to a fixed value, hide it from the schema, done. The model never sees the field; every call still goes to the right workspace.

Hiding a paginator

Most list tools have cursor and limit fields. Models tend to either ignore them (returning the first page when more was wanted) or set unhelpful values (limit: 1 to be safe). For agents that don’t need pagination, hide both fields and set sensible defaults so every call returns the full first page.

Narrowing an enum

A tool exposes a type field with 40 possible values. Your agent only needs three of them - the rest are noise that bloats the schema and confuses the model. Override type to a narrowed enum with just the three you care about.

Override via the dashboard

From the Tool Pack, click the Connector, then click the tool. The input override editor shows the tool’s full input schema with each field expandable. Per field, you can:

  • Hide it. Removes the field from what the model sees. If the field is required upstream, also set a default.
  • Set a default. A value Agent Handler will substitute when the model omits the field.
  • Force a value. A value Agent Handler will substitute regardless of what the model sends. The field is hidden from the model.
  • Relabel. Rename the field as the model sees it. The original name is used upstream.
  • Narrow. For enum fields, pick a subset of allowed values.

Override via the API

$curl -X POST https://ah-api.merge.dev/api/Connectors/$CONNECTOR_ID/tools/input-overrides \
>  -H "Authorization: Bearer $MERGE_AGENT_HANDLER_API_KEY" \
>  -H "Content-Type: application/json" \
>  -d '{
>    "tool_name": "slack__post_message",
>    "tool_pack_id": "tp_...",
>    "overrides": {
>      "workspace_id": { "force": "T01ACME" },
>      "channel": { "narrow_enum": ["general", "support", "ops"] },
>      "thread_ts": { "hide": true }
>    }
>  }'

Each override is keyed by field name. Combinations are allowed - you can hide and default the same field if the field is required upstream.

What input overrides don’t do

  • They don’t change the third party’s API. The full set of fields is still available; you just stop the model from picking them.
  • They don’t validate runtime values. If the model sends a value that violates the original (un-overridden) schema, the Connector will reject it before reaching the third party. Overrides shape the schema; they don’t relax type rules.
  • They don’t substitute for Tool Pack scoping. If you find yourself overriding so many fields that the tool is effectively a different tool, you probably want a custom MCP server with a purpose-built tool instead. See Custom MCP servers.

Order of effects

When a tool call comes in, Agent Handler processes overrides before the Connector dispatches:

  1. Forced values are applied first (overwriting whatever the model sent).
  2. Defaults fill in fields the model omitted.
  3. Hidden-and-not-defaulted fields are dropped from the call.
  4. Relabels are reversed back to the original field names.
  5. The result is sent to the Connector.

The agent and the third party see different views of the same call, which is exactly the point.

Next

Connect your agent to Agent Handler over MCP in MCP integration.