Skip to Content
OperateGovernancePrivate Registry

Private Registry

This page is for platform operators who roll out Arcade gateways to end users. Every gateway has a Private Registry: an authentication-gated page at the gateway URL where end users see the apps and tools the gateway gives them, interact with tool capabilities, and ask for what’s missing. Requests from every gateway in a land in one dashboard Inbox, ranked by how many people want them. We recommend using the Registry when your rollout grows past a pilot group and you can no longer walk each person through what their can do.

How it works

  1. You share the gateway URL with employees.
  2. An employee opens that URL in a browser and signs in the same way their client does.
  3. The Registry shows the apps and on that gateway, and which ones need the employee to log in first.
  4. When something is missing, the employee (or their ) files a capability request, or upvotes a request someone already filed.
  5. You review requests in the dashboard Inbox and respond. Employees on that gateway see your response.

The Registry only shows what the gateway already exposes. Filing or responding to a request never adds to a gateway or changes who can reach them. You enable new tools separately, by editing the gateway.

Share the Registry

The Registry URL is the gateway URL:

TEXT
https://api.arcade.dev/mcp/{YOUR-GATEWAY-SLUG}

A browser that opens this URL gets the Registry. An client that sends an MCP request to the same URL gets the gateway. You share one link for both.

To get the link from the dashboard:

Open the gateway list

Go to MCP gateways  in the Arcade dashboard.

Open the actions menu (⋮) on the gateway row. Under Employee registry, select Copy registry link to copy the URL, or Open registry to view it in a new tab.

Sign-in by gateway auth type

Every gateway has a Registry, whatever its authentication mode. The Registry detects which sign-in to show:

Gateway authenticationHow employees sign in to the Registry
Arcade AuthOAuth sign-in with their Arcade account, in a popup
User SourceOAuth sign-in through your identity provider, in a popup
Arcade HeadersA form that asks for an Arcade API key (Authorization) and a user ID (Arcade-User-ID)

On an Arcade Headers gateway, the ID is whatever the person signing in types. Arcade does not verify it, so Arcade attributes requests from that gateway to an unverified ID. Use Arcade Auth or a when you need to know who asked.

Security model

  • No sign-in bypass. Sharing the link does not grant access. Each visitor must sign in to the gateway before the Registry shows anything.
  • One gateway per page. The Registry browses only the gateway at its own URL. No query parameter or text field can point it at another server, so a shared link can’t land someone on a look-alike sign-in screen.
  • Tokens stay in memory. The access token and any header values live only in the open tab. Arcade does not write them to localStorage, sessionStorage, or cookies. Reloading or closing the tab signs the employee out.
  • Minimal browser storage. The Registry stores only request IDs in localStorage: requests the employee upvoted from that browser, and resolved requests they’ve already seen.

What employees see

After signing in, employees land on Your Apps: a card for each app on the gateway, with its tools and their login status. Tools that need the employee’s own show a lock, and their page has a Connect button. Tools that run without a login count as ready.

The Your Apps page with an app card for each app on the gateway, and locked tools in the sidebar

From there, employees can:

  • Browse by app. Select an app card or a sidebar entry to see that app’s .
  • Search. The sidebar search filters the list. When nothing matches, the sidebar offers to request it.
  • Try a . Each tool page has a Try section that builds an input form from the tool’s schema, runs the tool, and shows the result as a summary or raw JSON. The Registry warns before running a destructive tool.
  • Log in to an app. Connect starts that app’s authorization for the employee, one at a time.
  • Show Arcade . By default the Registry hides Arcade’s own tools, such as Arcade_ListApps. A switch at the top of the tool list shows them.

The Registry lists every tool the gateway allows, even if the gateway uses tool recommendation for agents. It never shows tools from other gateways, including other gateways in the same .

Capability requests

A capability request is free text that describes something an employee needs and can’t find, for example Cloudflare, mcp.cloudflare.com, or create Jira tickets from Slack threads. Each request belongs to the gateway where someone filed it.

Request from the Registry

Requests live in a chat-style bubble in the bottom-right corner of the Registry. Employees can also open it from:

  • Missing an app? Request it, next to the Your Apps heading
  • Request it, when a sidebar search matches nothing (the search text carries over)
  • Request a , in the sidebar footer

As the employee types, the bubble lists similar requests so they can upvote an existing one instead of filing a duplicate. Sending opens a review step that shows the message, explains that it goes to an administrator, and explains that others on the gateway can see and upvote it. Only Send to admin files the request.

The bubble shows every request on the gateway. A Show only my requests switch narrows the list to requests the employee filed or upvoted, and a badge counts their requests that you resolved since they last looked.

The request bubble opened from a sidebar search that matched nothing, with a similar existing request to upvote

Request through an agent

Any client connected to the gateway also gets four Registry tools, so can pass on a gap without the employee opening the Registry:

ToolWhat it does
Arcade_Registry_Get_Existing_SuggestionsSearch requests already filed on this gateway, most-supported first. Optional inputs: query, limit, offset, showResolved.
Arcade_Registry_Create_SuggestionFile a new request. Input: content, up to 1,000 characters.
Arcade_Registry_Support_SuggestionUpvote an existing request. Input: id from the search results.
Arcade_Registry_Get_My_SuggestionsList requests the signed-in employee filed, with their support count and, once resolved, resolved_at and resolution_notes.

The tool descriptions tell the to search before filing, upvote a match instead of duplicating it, and ask the employee before filing or upvoting. They also tell the agent that filing a request does not make the capability available.

For example, an employee on a gateway without Cloudflare tools asks their to purge a cache:

TEXT
Employee: Purge the Cloudflare cache for docs.example.com. Agent: This gateway doesn't have Cloudflare tools. Someone already asked for Cloudflare access, and 4 people support it. Want me to add your support? Employee: Yes. Agent: Done. You can ask me later whether your admins have responded.

Privacy and attribution

  • Search results never show who filed or upvoted a request. Only you, in the Inbox, see the submitter.
  • Arcade_Registry_Get_My_Suggestions returns only the signed-in employee’s own requests on the current gateway.
  • Upvoting your own request, or upvoting the same request twice, succeeds without adding support.
  • Arcade records submitters by user ID within the gateway’s identity scope: the Source, Arcade , or (for Arcade Headers) the .

Turn capability requests on or off

Capability requests are on for every gateway by default.

Per gateway. The gateway form in the dashboard has a Capability requests checkbox. Clear it to remove the four Registry from every connection to that gateway, and to hide the request bubble in its Registry. Through the API, this is the gateway’s tool_filter.registry_suggestions.enabled field.

Per connection. Add a query parameter to the gateway URL in an client’s configuration:

URL parameterEffect
registry_suggestions=falseHides the four Registry tools on this connection
arcade_tools=falseHides all of Arcade’s agent tools, including the Registry tools
TEXT
https://api.arcade.dev/mcp/{YOUR-GATEWAY-SLUG}?registry_suggestions=false

A URL parameter can only turn the off. If the gateway setting is off, registry_suggestions=true does not bring them back. While the tools are off, calls to them fail with tool not enabled for this gateway.

The Registry tools stay available whether or not the gateway uses recommendation, the same as Arcade_ListApps.

Review requests in the Inbox

Select Inbox in the dashboard sidebar to see open requests from every gateway in the , most-supported first. The sidebar badge counts open requests. To jump to one gateway’s requests, open the gateway’s actions menu (⋮) and select View suggestions inbox.

Each row shows the request text, the gateway it came from, the number of supporters, and the submitter’s ID. Filter the list with:

  • Search suggestions: matches request text
  • Gateways: one or more gateways
  • : one or more submitters
  • Include responded: shows resolved requests too

The filters are part of the page URL, so you can bookmark or share a filtered view.

The dashboard Inbox with requests from three gateways, including responded requests

Respond to a request

Open the request

Select Respond on an open request.

Write a response

Add an optional response of up to 1,000 characters, for example Added Cloudflare read-only tools to this gateway or Not approved for production data. Use the staging gateway instead.

The Respond dialog with an optional response

Send it

Select Respond. The request moves out of your open inbox. Employees on that gateway see it as resolved, along with your response.

To read a response later, turn on Include responded and select Response on the row.

Responding does not change the gateway. If you decide to add the capability, edit the gateway’s or add a remote MCP server as a separate step. Viewing the Inbox requires permission to read gateways; responding requires permission to update them.

Use the API

You can read and resolve requests with a , for example to sync them into your own ticketing system.

List requests

Terminal
curl -s "https://api.arcade.dev/v1/orgs/{org_id}/projects/{project_id}/suggestions?gateway_id={gateway_id}&limit=25" \ -H "Authorization: Bearer $ARCADE_API_KEY"
Query parameterTypeDefaultDescription
gateway_idstring, repeatableAll gateways in the projectOnly return requests from these gateways
querystringNoneCase-insensitive search over request text
suggestion_submitterstring, repeatableNoneOnly return requests from these submitter user IDs
show_resolvedbooleanfalseInclude resolved requests
limitinteger50Page size
offsetinteger0Number of requests to skip

Repeat a parameter to match any of its values, for example ?gateway_id=gw_1&gateway_id=gw_2. The most-supported requests come first.

JSON
{ "items": [ { "id": "2m4Q8vZcKx1yR7bT0nWfJdL3sHp", "gateway_id": "8b0e4f2a-3c1d-4e5f-9a6b-7c8d9e0f1a2b", "gateway_name": "Support team", "submitter_user_source_id": "us_okta_prod", "submitter_user_id": "jane@example.com", "content": "Cloudflare", "supporters": 4, "created_at": "2026-10-01T15:04:05Z", "resolved_at": null, "resolution_notes": null } ], "total_count": 1, "limit": 25, "offset": 0 }

Resolve a request

Terminal
curl -s -X POST "https://api.arcade.dev/v1/orgs/{org_id}/projects/{project_id}/gateways/{gateway_id}/suggestions/{suggestion_id}/resolve" \ -H "Authorization: Bearer $ARCADE_API_KEY" \ -H "Content-Type: application/json" \ -d '{"resolution_notes": "Added Cloudflare read-only tools to this gateway"}'

resolution_notes is optional. Resolving is idempotent: resolving an already-resolved request keeps its original resolved_at and resolution_notes.

Current limitations

  • A request is either open or resolved. Requests have no separate accepted or declined states, so put your decision in the response.
  • You can’t reopen a resolved request.
  • The Registry shows only the already on the gateway. It does not list Arcade tools you could add.

Next steps

Last updated on