Content

Tray.ai alternatives when agents change permissions

Tray.ai exposes connector operations as MCP tools an admin can open or close. Here is who reviews that change, and what to use when the model picks the call.

EngineeringOct 27, 2026

Key takeaways

  • -In this article we explore Tray.ai alternatives when an admin opens a new connector operation for an agent.
  • -To understand how a Tray Task works: one connector step is one Task, even if that step makes several API calls. Retries are not charged.
  • -Agent Gateway can expose reads and leave create, update, and delete off. Workspace membership alone does not grant a tool.
  • -A dashboard grant and a pull request on policies.json are reviewed in different places.

An admin in Tray.ai opens a write operation on a connector and publishes it as an MCP tool. The agent can now update records it could only read yesterday. Nobody opened a pull request. The change is an organization setting.

This post shows when Tray.ai is the right control for that permission change, and what to add when the model picks a call the workflow never listed.

What the Tray pricing page lists

The pricing page lists Pro, Team, and Enterprise as talk to sales. Pro includes 3 workspaces and 7-day insights and log retention. Team includes 20 workspaces and 30-day insights. Enterprise includes unlimited workspaces, 180-day insights, regional hosting, SSO, and HIPAA. The same page says Tray starts at $50 a month, and a free trial is how you size usage.

Usage is Tasks and Helix Compute Units. Tray defines a Task as one operation on a piece of data. The trigger is one Task. Each connector step is one Task. A step that makes several API calls still counts as one Task. Retries are not charged. There is no per-user or per-connection fee on that page.

Agent Gateway turns connector operations into MCP tools for Claude, OpenAI, Copilot Studio, or your own client. Tray does not host that model. Merlin's data note says only Owners and Admins enable the gateway, and admins choose which operations are exposed. You can expose reads and leave create, update, and delete off. Workspace membership alone does not grant a tool. The agent acts with the authentication you connected.

Where a low-code permission change fits

Use Tray when an integration owner should click a workflow into place and then decide which of those steps an outside agent may call.

The review is an admin action inside Tray. That matches a team that already lives in workspaces, wants 700 or more connectors as tools, and wants the call traced to a named user. Composite tools pack several steps into one MCP call so the model makes fewer choices.

You want that when the permission change is "this department may call this published tool." You have a weaker audit when the question is "did someone change the allowlist in git, and can I see the diff."

Who reviews the new permission

Two different people can widen access.

The Tray admin enables a write operation. From then on, every granted user of that MCP server can ask the model to call it. The model does not file a review. The admin already did, in the dashboard.

A developer changes policies.json and opens a pull request. The review is the diff: which method, which field, block or approval. Policy as code is that file. iPaaS and an execution layer explains why a designed workflow and a chosen call fail in different places.

Swytchcode does not replace Tray's workflow canvas. On the October 2026 pricing page, Free is 100 live commands a month with allow and deny. Approval on Slack or Telegram starts on Business at $149 a month. No answer within 48 hours, and the call does not run. You enable methods with swy add after swy list methods. A method you did not add cannot run, even if the model names it.

Picture a recruiter workflow that reads a candidate and creates a scorecard task. That composite tool is one MCP call, one reviewed surface. The day someone enables the "update offer" operation on the same connector, every granted user of that server can ask the model for an offer write. The workflow canvas did not change. The tool list did. A git review would show a new method id in tooling.json and a new block or approval in policies.json. A dashboard grant shows up in an audit trail if you remember to export it. Both can be valid. They fail in different rooms. If your security review lives in pull requests, the checkbox will not appear there. If your operators live in Tray workspaces, a CLI file will feel like a second system. Pick the room where the next permission change will actually be seen, and make the other system follow it.

Put the permission change in review

Follow this step to install the CLI. Use one of these.

npm install -g swytchcode
irm https://cli.swytchcode.com/install.ps1 | iex
curl -fsSL https://cli.swytchcode.com/install.sh | sh

Confirm the install, then start the project.

swy --version
swy init

Search the registry and download the bundle. Add only the read methods from the local list.

swy search <system>
swy get <name from search>
swy list methods
swy add <canonical_id from swy list methods>

Connect the provider before you enable a write. There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs.

swy auth connect <provider>
swy policy validate

Keep Tray for the workflow an admin publishes as one tool. When a new write would change what the agent can do, require a reviewed method ID and a policy, not only a checkbox in the workspace.

FAQ

Does a Tray Task equal one API call?

No. Tray's pricing page says a Task is one operation. A connector step that makes several API calls still counts as one Task. Retries are not charged.

Who can turn on a new MCP tool in Tray?

Owners and Admins enable Agent Gateway for the organization. Admins then choose which workflows and which connector operations are tools. Workspace membership alone does not let someone invoke them.

Can the agent do more than the user who connected?

Tray says the agent acts with the identity and permissions of the authentication used to connect. With dynamic user auth, each person's calls use that person's permissions. A dashboard grant can still expose a write the user did not intend the model to pick.

Should I move every Tray workflow into a CLI allowlist?

No. Leave stable, multi-step workflows in Tray, especially composite tools you already published. Use an allowlist for the call the model invents that was never one of those tools.

More content