Every MCP tool call, through one place you control
MCP servers are how coding agents get real tools: open a GitHub issue, update a Linear ticket, search Notion, query a database. Connecting one is easy. Connecting one for a whole team raises the questions a security review will ask:
- Where do the credentials live? Usually in a config file on every developer's laptop and in every CI runner, often as one shared token.
- Who does the call run as? With a shared token, every agent acts as the same bot account, so the tool's own audit trail can't say which person asked.
- What goes out, and what comes back? An agent can paste a secret into a tool call. A tool's result goes straight into the model's context, and it can carry text written to steer the model.
- What happened? Nobody has a record of which tools were called, by whom, with what.
Tempr's Gateway now answers those in one place. Remote MCP servers are added once, in the Portal, and every call Tempr's IDE extensions and CLI make to a remote server goes through the Gateway's MCP relay on its way to the server. Any other MCP client can use the same relay at /mcp/proxy/{server} with a Gateway key.
Credentials stay on the server
A server's address, its headers and every member's tokens are stored encrypted on Tempr's servers. The relay adds them to each request on the way out, so laptops, CI runners and editors never hold them. There's nothing to copy into a dotfile, nothing to leak from a laptop, and nothing to rotate on fifty machines when someone leaves.
Each call runs as the person asking
For servers that sign people in with OAuth, such as GitHub, Linear or Notion, you can turn on member sign-in. Each person then connects their own account, and the agent acts with that person's permissions. A ticket the agent opens shows who actually asked for it, and someone without access to a private repository can't reach it through the agent either.
Setting that up is usually the hard part of OAuth, so Tempr does it for you. It registers itself with the server's OAuth provider, using a Client ID Metadata Document where the provider supports one and dynamic registration otherwise, or uses an OAuth app you register yourself where a provider requires that, as GitHub does. Members' tokens are stored encrypted and refreshed when they expire, and they're revoked when someone signs out, is removed, or leaves the organization.
A member who hasn't signed in yet still sees the server's tools. Their first tool call asks them to sign in, using MCP's own request for it, and every Tempr client shows that as a link. The CLI prints it and opens it in your browser, and the IDE extensions show a sign-in link on the tool call, so signing in takes one click in the middle of a task.
Tool traffic is checked both ways
The relay reads every tool call and every result, and three checks run on them. You choose how strict each one is, for your account or your whole organization, and a key can override them:
- What goes out. Secrets and personal data in a tool call's arguments, such as bearer tokens, JWTs, AWS keys,
sk-style API keys, email addresses and card-like numbers, are flagged in the request log by default. Set it to block, and the call is refused and never sent. - What comes back. The same kinds of data in a tool's result are redacted by default, masked before the model ever reads them. Set it to block, and the whole result is withheld.
- Planted instructions. Text in a tool's result or description that's shaped like instructions to the model, such as "ignore previous instructions" or a fake system prompt, is flagged by default, or can be withheld. Hidden characters that can carry instructions a person can't see, such as zero-width spaces, Unicode tag characters and direction overrides, are removed.
We're careful about what this is. The checks catch the common shapes of secrets and injected instructions. They aren't a data-loss-prevention product, and no filter makes prompt injection impossible. What they give you is a first line of defence on the path every tool call takes, and a record of what they caught.
Tools can't change quietly
An MCP server describes its tools to the model: a name, a description and the input it expects. Those descriptions are instructions the model follows, and a server can change them at any time, including after your team has started relying on a tool that looked harmless.
So Tempr pins each tool's definition the first time it sees it. When a server changes a tool's name, description or input schema, the change goes to your organization's audit log, with the old and new description, and to your Gateway webhook as mcp.tool_changed. The tool keeps working, because most changes are ordinary updates, but nothing changes without your team being told.
What admins see
Every tool call is in the request log with its server, its tool, and anything that was flagged or redacted. Each Gateway key has its own list of allowed MCP servers and its own limits. For servers with member sign-in, owners and admins see who's signed in, with which account and scopes, and when it was last used, and they can revoke one member or everyone at once.
A few protections apply to every server, whatever its settings. The relay refuses private-network addresses and redirects, so a server entry can't be used to reach your internal network. And when a tool asks to be paid per call, the Gateway refuses it and never pays; the paid MCP tools post covers why.
Getting started
Add a remote server in the Portal under MCP servers, choose its sign-in setting, and set the guardrails under MCP credentials. Once you're signed in, every Tempr client can use it. The Gateway page has the overview, and the reference covers the guardrails and member sign-in in detail. Connecting servers in the IDE is in the MCP docs.