Uberall Platform MCP Server

The Uberall Platform MCP server is a hosted Model Context Protocol server that lets AI assistants and agents securely read, analyze, and update your Uberall data using natural language. It exposes Uberall capabilities across Locations Hub, Listings, Reviews, Social, Homepage, and Dashboard as MCP tools, and works with any MCP-compatible client.

It is a remote server: there is nothing to install or run locally. You connect your MCP client to a single HTTPS endpoint and authenticate with your Uberall account.

This hosted server replaces the previous local (stdio) uberall-mcp-server, which is now deprecated.

• An active Uberall account with access to the data you want to query. If you are not set up yet, get in touch (see Getting Started).
• An MCP-compatible client that supports remote, streamable-HTTP servers.
• One of the two supported authentication methods below. For the API-key method, see Get your API keys.

The server supports two ways to authenticate, depending on your account type.

Most users connect via OAuth 2.0. Your MCP client opens an Uberall login page in the browser; after you sign in and approve, the client is connected — no API key handling required.

Note: token refresh is not yet supported, so you will occasionally be asked to re-authenticate. While a session is active the experience is seamless.

Accounts with the API_ADMIN role can authenticate by sending their Uberall API key as a bearer token:

Authorization: Bearer <UBERALL_API_KEY>

Find your key under Org settings → API Keys in the Uberall app — see Get your API keys for the full walkthrough. Use the private server key (X-API-KEY / privateKey); for details on Uberall's keys and token lifecycle, see Authentication and versioning.

The server works with any MCP client that supports remote, streamable-HTTP servers. Point your client at the endpoint and authenticate with either OAuth or a bearer API key.

Most clients accept a JSON server definition like this (OAuth — the first request opens an Uberall login in your browser):

{
  "type": "http",
  "url": "https://mcp.uberall.com/mcp"
}

For API_ADMIN users, supply your API key as a bearer token instead (replace UBERALL_API_KEY):

{
  "type": "http",
  "url": "https://mcp.uberall.com/mcp",
  "headers": { "Authorization": "Bearer UBERALL_API_KEY" }
}

Refer to your MCP client's own documentation for where to register a remote/streamable-HTTP server — typically a settings screen, a CLI command, or a JSON config file. To try the server before wiring it into a client, you can also point the MCP Inspector at the endpoint above.

Most tools are read-only: they retrieve and analyze your Uberall data without changing it. A small number are write tools, marked WRITE in the tables below — these change your data or publish content to third-party directories. See Write tools before using them.

Each tool is exposed under a domain-prefixed name in the form <prefix>_<tool>. The tables below list the tool by its base name; the prefix for each domain is shown in its heading. For example, find_business in Locations Hub is exposed as locationsHub_find_business.

Headline performance and Location Performance Score (LPS) insights.

Analytics over a date range.

Most of this server is read-only. The tools marked WRITE above are not, and they behave differently enough to be worth reading about before you use them.

Because these tools act on live, customer-visible data, have your assistant show you the exact change before it calls them. Most MCP clients prompt for confirmation on tools that declare themselves as modifying data; all four do.

None of the write tools are retried automatically. A retried reply would post the same text twice, publicly, so a failure is surfaced rather than silently repeated. If a call fails, confirm before retrying.

update_location is a partial update: only the fields you pass are changed, and everything you omit is left exactly as it is. To clear a field, pass it as an empty string. A call that supplies no fields at all is rejected rather than treated as a no-op.

Changing the location's name, country, street, ZIP, city, province, phone, or primary category can send its Google and Facebook listings back into re-verification, which temporarily affects visibility. The tool warns about this on each of those fields.

If your user lacks write permission for a field, the API silently drops that field rather than failing the call — the tool surfaces those dropped fields in its response, so check them instead of assuming everything applied.

The tool covers the core listing record only: name, address, contact details, opening hours, descriptions, keywords, categories, and status. Photos, videos, social profiles, custom fields, and other extended content are not updatable through it. Neither is bulk editing — update one location per call.

Replying needs the right ID, and the one you want is not always the obvious one.

To post a new reply, pass the dataPointId of the review you are answering, taken from a get_feed_items result.

To edit or delete an existing reply, you need the reply's own ID, and get_feed_items does not return it — it returns top-level items only, and the ownerReply field shows the reply's text but carries no ID. Resolve it in three steps:

1. get_feed_items → find the review, take its composite id (e.g. v2_google_review_3031865_1000025977).
2. get_feed_item_children with that id → find the child with author.isClient = true, which is the business's own reply.
3. Pass that child's dataPointId to edit_review_reply or delete_review_reply.

Two IDs to avoid: the composite id is not accepted by the write tools, and dataPointSourceId identifies the listing rather than the item — it is the same value for every item from a location, so passing it acts on the wrong record instead of failing loudly.

Passing the review's dataPointId to delete_review_reply deletes the customer's review rather than your reply to it. Confirm which item is meant before calling.

On accounts with the reply-approval feature enabled, a reply is not published when it is submitted — it is queued for a person to approve. The tool response says which happened: check the warnings list, and fall back to the reply's entry under dataPoint.comments (or dataPoint.approvalNeeded) if warnings is empty. Do not assume a successful call means the reply is live.

Approving and rejecting queued replies is deliberately not available through this server. That review step exists so a person sees the text before it goes public, so it stays with a person.

Publication is also asynchronous in every case: a successful response means the reply was accepted by Uberall, not that it is already visible on the directory.

Once connected, ask your assistant natural-language questions such as:

• "Which of my locations are disconnected from Google, and how do I reconnect them?"
• "Summarize the reviews with fewer than 3 stars from the last 30 days."
• "Show the listing sync status for location 2946407."
• "Find all businesses on the Advanced product plan with more than 50 locations."
• "How have my impressions and clicks trended over the last 30 days, and which locations have the lowest performance score?"
• "Which of my locations are missing a phone number?"
• "Update the opening hours for location 2946407 to close at 6pm on Saturdays."
• "Draft a reply to the 2-star review of the Berlin store from last week, show it to me, and post it once I approve."

Why am I occasionally asked to sign in again? Token refresh is not yet supported for OAuth, so sessions are not renewed automatically — browser clients re-authenticate more often than desktop apps. Separately, Uberall access tokens require a fresh manual login after long inactivity; see Access Token Lifecycle.

I get a 401 / "unauthorized" error. For OAuth, make sure you completed the browser sign-in. For the API-key method, confirm the bearer token belongs to an API_ADMIN account and is the private server key — see Get your API keys.

No tools show up, or the connector won't connect. Check that the URL is exactly https://mcp.uberall.com/mcp, that your client supports remote streamable-HTTP servers, and that authentication completed. Remote MCP servers can also be blocked by a corporate VPN or firewall.

Can I try it without touching production data? Yes — point the connector at the sandbox endpoint https://mcp.sandbox.uberall.com/mcp. See the Sandbox Environment for what it supports.

Questions or issues: api@uberall.com.

For how Uberall handles your data, see the Privacy Policy.