Skip to main content
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.

The vendor’s MCP server has no tool enable/disable settings — can I still disable individual tools?

Yes — regardless of whether the upstream server supports it. Which tools a gateway exposes from each server is controlled by feature provisioning, and MCP Manager itself enforces it: a hidden tool is invisible to clients and uncallable, and a direct call to it is blocked and logged. The upstream server’s own settings play no part, so a vendor that offers no tool-level enable/disable controls is governed exactly like one that does. See Feature Governance for the security model.

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?

Yes. MCP Manager emits both the OpenTelemetry logs and traces signals over OTLP/HTTP (metrics are not exported). For each proxied MCP request the gateway creates a span carrying the method, organization, gateway, tool, and response status, and exports it to a traces collector URL you configure — giving you a real request waterfall, not just log lines. Trace context propagates into downstream MCP servers over W3C traceparent (both the HTTP header and the JSON-RPC params._meta), so the gateway → upstream hop joins one trace. Every log record is also stamped with the request’s traceId/spanId, so logs correlate to the trace even if you forward logs only. Two layers of correlation are available: the older correlation_id (also sent upstream as the x-correlation-id header) ties the four legs of one request together within MCP Manager’s records, and the OTLP trace context ties them across services. Configure a logs URL, a traces URL, or both. 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.

Is MCP Manager down? Where can I check status or report an outage?

Check the live status page at status.mcpmanager.ai for current uptime, any ongoing incident, and historical reliability. If you’re seeing connection failures or degraded performance, the status page is the fastest way to tell whether it’s a platform-wide incident or something specific to your setup — and you can subscribe there to be notified when an incident is opened or resolved.

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.

Is there a limit on how large a tool response can be?

There is, though you’re unlikely to ever reach it. The gateway accepts a single response of up to 16 MB — comfortably larger than what tools return in everyday use, so normal traffic flows straight through. If a response does go over, you’ll get a clear MCP error rather than a half-delivered result. The limit is there for a good reason: the gateway reads each response in full to check it for leaked secrets and injected content, and capping the size keeps one unusually large response from crowding out everyone else sharing the platform. See Architecture & Trust.

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.