handling-held-and-refused-calls

by Omniio

Respond correctly when an Omniio tool call is held for human approval, denied by policy, or refused for a spent approval. Use when run_tool returns a message about approval, a link to approve or deny, a policy denial, or an input_required result rather than a normal tool result. A held call is not a failure and must not be reported as one.

Using this gatewayAlways on1 file

What it tells an agent to do.

The author’s own instructions, as your agent receives them — the same bytes the endpoint serves.

When a call is held or refused

An Omniio account can set any tool to ask first. When it does, run_tool stops before the call reaches its server and waits for a person.

This is a feature working, not an error. Reporting "the tool failed" or "I don't have access" when a call is merely waiting is the wrong answer, and it is the most common mistake against this gateway.

Held for approval

You will get one of two shapes, depending on what your client supports.

If your client handles input requests, the result is an input_required carrying a URL. Surface that URL to the user, wait, and the original call resumes on its own with the real result. Do not start a new call.

Otherwise, the result is text along the lines of:

"github__create_issue" needs approval before it can run. Approve or deny it at https://omniio.dev/app/tools/approvals/…

Then:

  1. Tell the user, in your own words, that the call is waiting and what it will do once approved.
  2. Give them the link exactly as provided. Do not shorten or reconstruct it.
  3. Stop. Do not retry in a loop — a still-pending request means nobody has decided yet, and calling again just queues another one.
  4. When they say they have approved it, call run_tool again with the same arguments.

Approvals are single-use, and bound to the arguments

An approval covers one call with one set of arguments. If you retry with anything changed, it is a new request and needs a new decision.

You may also see:

was approved, but another call with the same arguments used that approval first — approvals are single-use.

That means the call almost certainly already ran. Check before repeating it: re-running a write because an approval was spent is how one issue becomes two.

Denied

"…" was denied by the account owner and was not run.

Accept it. Do not rephrase the request and try again — the person said no to the action, not to the wording. Say what was declined and offer an alternative that does not need it.

Denied by policy

"…" is denied by your Omniio tool policy and was not run. Change it at https://omniio.dev/app/tools

The account has this tool switched off. There is nothing to wait for and no point retrying. Tell the user which tool is blocked and where the setting lives, then continue without it.

What not to do

  • Do not treat a hold as a permissions problem with your own credentials.
  • Do not retry a held call on a timer.
  • Do not try a different tool that does the same thing to route around a policy denial. The account switched it off on purpose.
  • Do not invent an approval URL. Use the one you were given, or none.

More in using this gateway

finding-and-calling-tools

Omniio

Find and correctly call a tool on an Omniio MCP gateway. Use whenever a request could be served by an external system — live data, a lookup, or an action in a c

What it does →

connecting-a-server

Omniio

Diagnose and explain why a tool the user expected is missing from an Omniio gateway, and tell them exactly how to connect the server that provides it. Use when

What it does →

limits-and-retries

Omniio

Decide whether a failed Omniio call should be retried, and how long to wait. Use when a tool call or REST request returns a rate limit, a quota message, a 4xx o

What it does →