Frequently Asked Questions

Answers to common MCP Manager questions: restricting a data source to specific tables, projects, channels, or folders; scoping who can use a single server such as Salesforce; whether a user can hold multiple roles and teams; applying different rules or tools to different groups by using separate gateways; whether there is a REST API to pull logs by session ID; whether MCP Manager supports OpenTelemetry traces as well as logs; where MCP Manager is hosted; and provisioning programmatically.

Short answers to questions that come up often about MCP Manager. Each answer links to the page with the full detail.

Can I restrict a data source to specific tables, projects, channels, or folders?

Scope it at the source. MCP Manager governs which servers and tools are reachable and can inspect the traffic, but it does not re-implement each data source’s own permissions for tables, projects, channels, or folders. The supported way to narrow a source is to connect it with a credential or service account that already has only the access you intend to expose — a database role limited to certain schemas, a Slack token limited to certain channels, an Asana service account added only to specific projects, or a Google service account scoped to certain folders. The gateway rules engine is a backstop for content — blocking or redacting sensitive data in results — not a replacement for source-side scoping. Pair narrowly-scoped credentials with identity controls so each user reaches the source as themselves, with their own permissions.

For content- or path-level enforcement at the gateway — for example, blocking results that reference a particular Google Drive folder — you can build a custom rule engine that inspects tool calls and their results and blocks or redacts them. Gateway rules act on tool traffic, so this complements source-side scoping rather than replacing it.

Can I make someone an admin of just one server, like Salesforce?

You can control who can use a single server, but you cannot grant management powers over only that one server. Capabilities in MCP Manager are workspace-wide — there is no per-gateway or per-server admin role. To restrict use of one server, put it in its own gateway and provision that gateway only to the team that should have it, so only those users can connect to it. Management capabilities themselves — creating gateways, exporting logs, managing integrations — are granted by capabilities at the workspace level. So “only the Salesforce team can use the Salesforce server” is fully supported; “an administrator of only the Salesforce server” is not.

Can a user have multiple roles and multiple teams?

A user has exactly one role and can belong to many teams. The split is deliberate: a role is the single, workspace-wide answer to “what is this person allowed to do,” so keeping it to one role means there’s never a conflict to resolve between two overlapping permission sets. Teams answer a different question — “which gateways can this person reach” — and they’re additive, so adding someone to more teams simply unions the gateways available to them. To change what someone can do, change their role; to change what they can reach, adjust their team membership. See Access Control.

Can I apply different rules or expose different tools to different groups of people?

Yes — by giving them different gateways. The gateway is the smallest unit of governance in MCP Manager: gateway rules, the tools and resources each server exposes, and the per-server identity scheme are all configured on the gateway. There is no setting below the gateway level that applies a different rule set or tool set to some users but not others on the same gateway. So when one group needs a different policy — a stricter rule, a narrower tool set, a different identity scheme — you create another gateway with that configuration and provision it to the right team. Standing up another gateway is inexpensive, and doing so is the intended way to vary governance rather than looking for a finer-grained control inside a single gateway.

Is there a REST API to pull logs, for example by session ID?

No. MCP Manager does not expose a public API to query or pull logs, including by session ID. MCP Manager records every request and response as a log, which you can view and export in the app and — the path for programmatic access — forward to your own observability or SIEM platform over OpenTelemetry. To query logs by session ID, correlation ID, user, or any other field from code, send them to your own tool (Datadog, Grafana, Splunk, Honeycomb, and others) and query them there. See Export to SIEM.

Does MCP Manager support OpenTelemetry traces, not just logs?

Today MCP Manager emits the OpenTelemetry logs signal — not traces or metrics — and forwards it to your collector over OTLP/HTTP. Correlation is still first-class: every log record carries a correlation_id (also sent to the upstream server as the x-correlation-id header) that ties the four legs of a single MCP request together, so you can reconstruct one exchange end to end across the client, the gateway, and the downstream server. Full distributed traces and spans — traceId/spanId on every record and W3C traceparent propagation into downstream services — are a near-term addition as we keep expanding logging context. See Audit & Observability and Export to SIEM.

Where is MCP Manager hosted, and do you offer EU data residency or on-premise?

MCP Manager is a hosted service running on Google Cloud Platform in the United States. There is no self-hosted or on-premise version, and EU data residency is not available today. See Hosting & Data Residency for the full picture, including what you can run in your own environment.

Can I provision gateways and connections with an API, CLI, or Terraform?

Not yet. A control-plane API, CLI, and MCP-based provisioning are in active development and not generally available; gateways, connections, and identities are created in the app today. What ships now is token-based agent connection and per-user identity passing. See Programmatic Access.

Can one agent act as many different users?

Yes. A single token-based host can serve many end users while using each user’s own downstream credential, so every action runs as the real person and is logged as them. See Agents that Pass Identities to MCP Manager.

Further reading

Identity Controls

How each user reaches a downstream server as themselves, with their own permissions.

Capabilities

The workspace-wide capabilities that decide what a role can do.

Gateway Deployment Strategies

Isolating a single server in its own gateway, and other topologies.

Export to SIEM

Forward logs over OpenTelemetry and query them in your own tool.