OrgRelay

Connect a vendor's MCP server

More platforms now ship their own MCP server. OrgRelay can connect to one directly, with no OrgRelay manifest and no code, and still put approvals, permissions and an audit log in front of it.

This route sits between building a connector and using a ready-made one from the connector directory. A list of vendor servers we have checked, with their auth methods, is on official MCP servers.

Set it up

  1. Admin → Business systems → Add connection → MCP.
  2. Enter the vendor's MCP URL and credentials. Bearer tokens and OAuth 2.1 client credentials are supported; see authentication.
  3. Click Read system information. OrgRelay runs initialize and tools/list. If there is no orgrelay://connector/manifest resource, it treats the server as third-party.
  4. Review the tools, switch off the ones staff should not use, and grant the connection to roles or departments.

What OrgRelay does with a vendor's tools

Aspect Behaviour
Name shown The server's serverInfo.title or name; otherwise the hostname
Tool names Rewritten to domain.action. The domain is the server name in lower-case letters and digits (up to 16), the action is the vendor tool name in snake case. The original name is kept and sent back on each call
Read or write Read only if annotations.readOnlyHint is true. Missing or false means write, so approval is required
Limit First 100 tools
Descriptions Kept, clipped to 800 characters

So a server named shopify-dev with a tool searchOrders marked read-only becomes shopifydev.search_orders, read. A tool with no annotations becomes a write tool. That default is deliberate: an unlabelled tool might delete something, and the cost of being wrong is one extra approval.

What OrgRelay adds

A vendor MCP server is usually designed for one person using one AI client. Inside a company, OrgRelay adds:

  • Per-role access. Only granted roles and departments see the tools; the request never leaves OrgRelay otherwise.
  • Approval before writes. Every non-read tool creates an approval request. See approvals and write tools.
  • One audit log across the vendor server, your own connectors and company documents.
  • Shared credentials stay on the company's machine. Staff do not each need the vendor token.

Owners see the same thing from the business side on orgrelay.com's approvals page.

What you give up

Native connector Third-party MCP
Standard tool names route tools to department agents Vendor names, so only the AI Chief and explicitly granted roles use them
Idempotency key on every approved write Only if the vendor's tool accepts one
Four-language names and descriptions Whatever the vendor provides
Manifest declares read or write Inferred from readOnlyHint

For heavily used platforms a native connector is usually worth it. For a quick start, or a platform used by one team, a vendor server is fine.

Remote servers that require user OAuth

Some vendor servers only accept a per-user OAuth flow in a browser, designed for Claude.ai or ChatGPT. OrgRelay connects as a service with a token or client credentials. If a vendor offers only interactive user OAuth, use its API through OpenAPI import or a connector template instead.

Automation platforms

Zapier, Make and n8n can expose workflows as MCP tools. Connected this way, each workflow is a tool. Mark read-only workflows with readOnlyHint: true where the platform allows it; everything else will go through approval, which is usually what you want for workflows that send emails or create records.

Common questions

Why are most vendor tools write? There is no manifest, so OrgRelay trusts only an explicit readOnlyHint: true.

What do I lose versus a native connector? Agent routing and guaranteed idempotency. Approvals, permissions and the log stay.

Zapier, Make, n8n? Yes, through their MCP endpoints.

Next

Updated (Singapore time) · OrgRelay Team