# Metorial Answers, complete text

Every answer published at https://metorial.com/answers, inlined in full.
Index with descriptions only: https://metorial.com/answers/llms.txt
Metorial product and API index: https://metorial.com/llms.txt

Documents: 10
Generated from: https://metorial.com/answers

---

# How to Connect Salesforce to Claude Securely

> **Answer.** Connect Salesforce to Claude through an MCP gateway rather than by pasting an API key into a local config. Set up the Salesforce integration, grant it to the right group, add the gateway endpoint to Claude, and start read-only. Each person then authenticates as themselves, so an agent can only reach the records that person could already reach, and every call is recorded with their identity.

- Question: how to connect Salesforce to Claude
- Canonical: https://metorial.com/answers/connect-salesforce-to-claude
- Last updated: 2026-08-25
- Reviewed by: Karim Rahme, Metorial

---

There are two ways to do this, and they differ in who the agent acts as. The local route is faster to set up and gives every user the permissions of whoever created the key. The gateway route takes a few more minutes and preserves each person's own access.

| If this is for | Use |
| --- | --- |
| One developer testing on a sandbox org | A local MCP server with your own credentials |
| A team sharing access to production | A gateway with per-user OAuth |
| Sales or support staff who do not write code | A gateway, with tools granted by role |
| An org under audit or data residency rules | A gateway you can self-host |

## What do you need before starting?

- A Salesforce org where you can authorize a connected app, or an administrator who can.
- Claude Desktop, Claude Code, or any MCP-capable client.
- A Metorial account. The [Dev plan](https://metorial.com/pricing) is free.
- A decision on read-only versus read-write. Start read-only.

## How do you connect Salesforce to Claude?

**1. Set up the integration.**

```sh
npm install -g @metorial/cli
metorial login
metorial integrations setup salesforce
```

This runs the Salesforce OAuth flow and stores the tokens against your user, including refresh. No key is written to a file on your machine.

**2. Check which tools it exposes.**

```sh
metorial integrations tools salesforce
```

Read the list before granting it. You are deciding what an agent can do on behalf of a person, and the read tools are almost always where the value is.

**3. Grant it to the right group.**

In [Access control](https://metorial.com/access-control), bind the integration to the group that should have it, such as revenue operations, rather than to individuals. Group membership then comes from your identity provider, so a new hire gets access on day one and loses it on their last without anyone editing a list.

**4. Add the endpoint to Claude.**

[Magic MCP](https://metorial.com/magic-mcp) gives you one URL that carries the tools that user is entitled to. Add it as an MCP server in Claude's settings. The same URL works in Cursor, Codex, and Copilot, so this step does not repeat per client.

**5. Verify it works, as the right person.**

Ask Claude for something scoped: *"Summarize the open opportunities on the Acme account."* Then check the record:

```sh
metorial sessions list
```

The session should name the tool, the arguments, and your identity. If the identity field shows a connection rather than a person, the setup is not per-user and the rest of this does not hold.

## How does per-user authentication change what the agent can reach?

This is the part worth understanding before rolling it out further.

With a shared API key, every user's agent inherits the permissions of whoever created that key. Someone in support can reach every record it can reach, which is usually far more than their own profile allows.

With per-user OAuth, the call runs under that person's Salesforce credentials, so profile permissions, sharing rules, and field-level security apply exactly as they do when that person uses the Salesforce UI. You are not building a second permission model; you are inheriting the one Salesforce already enforces.

## Should you allow writes?

Not initially. Read-only for the first two weeks, then review the sessions and see what people actually asked for. Enable writes for specific objects and specific roles after that.

Salesforce is the system where an over-permissioned agent does the most visible damage, and reads deliver most of the value anyway: summarizing a pipeline, drafting follow-ups, and answering questions about accounts are all read operations.

## What about prompt injection?

Salesforce records contain free text that users and sometimes external parties wrote. An agent that reads a note containing instructions may follow them.

[Protoguard](https://metorial.com/protoguard) inspects calls for injection before they execute, which reduces this risk without eliminating it. Combined with read-only access and narrow scopes, it keeps the blast radius small. The broader picture is in [Are MCP servers secure?](https://metorial.com/answers/are-mcp-servers-secure).

## Does this pattern work for other systems?

Yes, and the steps do not change. Substitute the integration name:

```sh
metorial integrations setup slack
metorial integrations setup github
metorial integrations setup google-workspace
```

Same OAuth flow, same role-based grant, same endpoint, same session records. That consistency is most of the argument for a gateway once you are connecting the third system rather than the first.

## Next step

Set up the integration and confirm what the first session recorded:

```sh
npm install -g @metorial/cli
metorial login
metorial integrations setup salesforce
metorial sessions list
```

See the [Salesforce integration](https://metorial.com/integrations/salesforce) for the tool list, and [Access control](https://metorial.com/access-control) for granting it by role.

## Frequently asked questions

### Can Claude connect to Salesforce directly?

Claude can connect to any MCP server, including a Salesforce one you run locally. What it does not provide is per-user authentication, role-based tool scoping, or a shared audit record, which is why company deployments put a gateway in between.

### Will the agent see records the user should not see?

Not with per-user OAuth. Each call runs under that person's own Salesforce credentials, so profile, sharing rules, and field-level security apply exactly as they do in the UI. A shared API key removes that boundary, which is the main risk of the local setup.

### Should we allow writes to Salesforce?

Not at first. Start read-only, watch the session records for a week or two, then enable writes for specific objects and specific roles. Salesforce is where an over-permissioned agent causes visible damage fastest.

### Does this work with Cursor, Codex, or Copilot too?

Yes. The endpoint is the same MCP URL, so the same integration and the same access rules apply across clients. Switching or adding a client does not mean redoing the connection.

### What does a Salesforce tool call record contain?

The tool called, the arguments including the object and record, the result or error, the session, and the identity the call ran as. That last field is what lets you answer who an agent acted for during a review.

## Sources

1. [Salesforce OAuth 2.0 authorization flows](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_flows.htm&type=5)
2. [Model Context Protocol specification](https://modelcontextprotocol.io)
3. [Metorial documentation: Integrations overview](https://metorial.com/docs/integrations-overview)

---

# Best AI Agent Observability and Tracing Tools (2026)

> **Answer.** Agent observability splits in two. LLM-level tools such as LangSmith, Langfuse, Braintrust, and Arize Phoenix trace prompts, tokens, and model quality. Tool-level tools such as Metorial Tracing record what the agent actually did in external systems and under whose identity. Most teams debugging production agents need both, because a prompt trace cannot tell you which record got updated.

- Question: best AI agent observability tools
- Canonical: https://metorial.com/answers/best-ai-agent-observability-tools
- Last updated: 2026-08-25
- Reviewed by: Karim Rahme, Metorial

---

Most "agent observability" comparisons list tools that answer only one of two different questions. Deciding which question you have first makes the choice straightforward.

| If the question you need answered is | You need |
| --- | --- |
| Why did the agent decide that? | LLM tracing: LangSmith, Langfuse, Braintrust, Phoenix |
| What did the agent actually change? | Tool-level tracing: Metorial Tracing |
| Whose permissions did that call run under? | Tool-level tracing with identity |
| Why did the bill go up? | LLM tracing with token accounting |
| Is the output getting worse over time? | An evaluation tool: Braintrust, Langfuse, Phoenix |
| What happened in this incident? | Both |

## Why the two categories are not interchangeable

An LLM trace shows the prompt, the model's reasoning, the tokens consumed, and the response. It answers questions about the decision.

A tool trace shows which tool was called, with what arguments, what came back, and under whose identity. It answers questions about the effect.

When an agent updates the wrong Salesforce record, the prompt trace tells you why the model thought it should. Only the tool trace tells you which record, and only it names the person whose credentials were used. Security reviews ask for the second one, and it is the one teams more often lack.

## LLM-level tracing

### Langfuse

**Best for:** Teams that want open source and self-hosting.

Tracing, prompt management, and evaluation, self-hostable, with an active community. The default recommendation when data cannot leave your infrastructure.

**Where it falls short.** Tool-call visibility is only as good as what your application instruments, and it carries no identity context of its own.

### LangSmith

**Best for:** Teams already building on LangChain or LangGraph.

The tightest integration with that ecosystem, and the least setup work if you are already in it.

**Where it falls short.** Most valuable inside its own ecosystem, and hosted-first.

### Braintrust

**Best for:** Teams whose main problem is output quality rather than debugging.

Strong on evaluation and comparing prompt or model versions against datasets.

**Where it falls short.** Evaluation-led rather than incident-led, so it is not the tool you reach for at 2am.

### Arize Phoenix

**Best for:** Teams that already run an OpenTelemetry-based stack.

Open source, OpenTelemetry-native, so traces land beside your existing application telemetry.

**Where it falls short.** More assembly required, and no notion of which user a tool call acted for.

## Tool-level tracing

### Metorial Tracing

**Best for:** Anyone running agents that write to external systems.

[Tracing](https://metorial.com/tracing) records every session at the gateway rather than inside your application: the tool called, the arguments, the result, and the identity behind it. Because it sits on the call path, coverage does not depend on each application remembering to instrument itself, which is where in-application tracing usually develops gaps.

The identity field is the part that matters most and is hardest to add later. It is what makes a session record usable in an incident review, and it exists because the same layer runs the per-user OAuth. [Protoguard](https://metorial.com/protoguard) annotates the same records with prompt injection findings.

**Where it falls short.** It is not an LLM observability tool. It does not trace prompts, count tokens, or evaluate output quality, so if your problem is model quality or spend, pair it with one of the tools above rather than replacing them.

## Who should pick what?

- **Langfuse** if you want open source and self-hosting for prompt-level tracing.
- **LangSmith** if you are already on LangChain.
- **Braintrust** if evaluation and regression testing are the priority.
- **Arize Phoenix** if you want OpenTelemetry and already run that stack.
- **Metorial Tracing** if agents act in external systems and you need to know what they did and as whom.
- **One of each** for production agents with write access, which is the configuration most teams end up at.

## What should you check before committing?

- Does the trace name the acting user, or only the application?
- Are arguments and results captured, or only tool names?
- How long is retention by default, and can it be extended?
- Does coverage depend on each application instrumenting itself?
- Can traces be exported, or are they trapped in the vendor's interface?

## Next step

Look at what a session record contains for a call you have already made:

```sh
npm install -g @metorial/cli
metorial login
metorial sessions list
```

[Tracing](https://metorial.com/tracing) covers the session model, and [Are MCP servers secure?](https://metorial.com/answers/are-mcp-servers-secure) covers why the identity field matters in a review.

## Frequently asked questions

### What is the difference between LLM observability and agent observability?

LLM observability traces what went into and came out of the model: prompts, tokens, latency, cost, and output quality. Agent observability also covers the side effects, meaning which tools were called with which arguments, what came back, and which identity the call ran as.

### Do I need both an LLM tracing tool and tool-level tracing?

For production agents that write to external systems, yes. A prompt trace explains why the agent decided something; a tool trace shows what it actually changed. Incident response and security reviews both need the second, and neither is derivable from the other.

### Is OpenTelemetry usable for agent tracing?

Yes, and several tools emit OpenTelemetry spans, which lets agent traces land in the observability stack you already run. The gap is semantics: generic spans do not carry the identity a tool call ran under unless something adds it.

### What should a tool call trace contain?

The tool name, the arguments, the result or error, the timestamp, the session it belongs to, and the identity the call ran as. The identity is the field most often missing and the one a security review asks for first.

### How long should agent traces be retained?

Long enough to cover your incident review window and any compliance obligation, which for most teams means months rather than days. Confirm the retention period and whether it can be extended before committing, since defaults are often short.

## Sources

1. [OpenTelemetry](https://opentelemetry.io)
2. [Langfuse (open source LLM engineering platform)](https://langfuse.com)
3. [Arize Phoenix](https://phoenix.arize.com)
4. [Metorial Tracing](https://metorial.com/tracing)

---

# Best MCP Servers for Enterprise Teams (2026)

> **Answer.** The MCP servers worth deploying first are the ones covering systems most of the company already touches: GitHub for engineering, Slack for context, Salesforce for revenue teams, Google Workspace for documents, Jira and Linear for tracking, Notion or Confluence for knowledge, and your data warehouse for analysis. What makes a server enterprise-ready is per-user authentication, scoped permissions, and a record of every call, not the length of its tool list.

- Question: best MCP servers for enterprise
- Canonical: https://metorial.com/answers/best-mcp-servers-enterprise
- Last updated: 2026-08-25
- Reviewed by: Karim Rahme, Metorial

---

Rank by how many people a server unblocks, not by how many tools it exposes. The systems below are the ones that recur across almost every deployment, in roughly the order they earn their place.

| If your first users are in | Start with |
| --- | --- |
| Engineering | GitHub, Linear or Jira, Sentry |
| Sales or revenue operations | Salesforce or HubSpot, Slack |
| Support | Zendesk or Intercom, Notion or Confluence |
| Finance or operations | Google Workspace, the data warehouse |
| Everyone at once | Slack plus Google Workspace, then add by team |

## What actually makes a server enterprise-ready?

Three properties, and none of them is tool count.

**Per-user authentication.** Each person authenticates individually, so a call is bounded by what that person could already do. A server that only accepts a single API key gives every user the permissions of whoever created the key.

**Scoped permissions.** Read and write should be separable, and access should be grantable by role. "Can read Salesforce opportunities" and "can update them" are different decisions.

**A record.** Every call logged with arguments, result, and acting identity. Without it, no one can answer what an agent did.

## The servers worth deploying first

### GitHub: engineering context

**Best for:** Engineering teams, and any agent that needs to know what shipped.

Issues, pull requests, code search, and CI status. The highest-value first server for most companies, because it turns "what changed and why" into something an agent can answer. Scope reads broadly and writes narrowly.

### Slack: the context nothing else has

**Best for:** Almost everyone, once more than one team is using AI.

Most decisions are explained in Slack and nowhere else, which makes it disproportionately useful as context. It is also the server where per-user authentication matters most, since channel membership is the permission boundary and a shared connection destroys it.

### Salesforce: revenue teams

**Best for:** Sales, revenue operations, and customer success.

Accounts, opportunities, and contacts. Start read-only. Salesforce is where an over-permissioned agent does visible damage fastest, and where the value of per-user scoping is easiest to demonstrate. See [How to connect Salesforce to Claude securely](https://metorial.com/answers/connect-salesforce-to-claude).

### Google Workspace: documents and calendars

**Best for:** Every non-engineering function.

Docs, Sheets, Drive, Calendar, Gmail. Broad usefulness and correspondingly broad risk, so this is the clearest case for narrow OAuth scopes rather than full account access.

### Jira and Linear: tracking

**Best for:** Teams whose work is planned in a tracker.

Reading a board to summarize status is safe and immediately useful. Writing to it is where teams usually want an approval step first.

### Notion and Confluence: knowledge

**Best for:** Support, operations, and onboarding.

Internal documentation is the highest-quality grounding data most companies have. It is also where stale pages produce confident wrong answers, so treat freshness as part of the rollout rather than an afterthought.

### The data warehouse: analysis

**Best for:** Analysts and anyone asking questions about numbers.

Snowflake, BigQuery, Postgres. Read-only, against views rather than raw tables, with row-level security intact. Done that way it is one of the safest servers to run; done carelessly it is the least safe.

## What about the long tail?

Past the first handful, coverage matters more than curation. The [Metorial catalog](https://metorial.com/integrations) has over 1,000 integrations, [mcp-index](https://github.com/metorial/mcp-index) catalogs the public ecosystem, and [mcp-containers](https://github.com/metorial/mcp-containers) provides prebuilt images for self-hosting.

For internal systems with no public server, wrap the API in a custom one. That is when running everything behind a single gateway pays off, because the internal server inherits the same authentication, policy, and logging as everything else instead of needing its own.

## How should you actually roll these out?

- Start with two or three servers, chosen by how many people they unblock.
- Read-only first for anything holding customer or financial data.
- Scope tools by role, so nobody sees a list of two hundred tools. This also improves how reliably the model picks the right one.
- Confirm the audit record names the person, not the connection, before widening access.
- Add servers when someone asks for one, not in anticipation.

## Next step

Browse [1,000+ integrations](https://metorial.com/integrations), or connect the first two from the command line:

```sh
npm install -g @metorial/cli
metorial login
metorial integrations setup github
metorial integrations setup slack
```

[Access control](https://metorial.com/access-control) covers scoping tools by role before you widen access.

## Frequently asked questions

### What makes an MCP server enterprise-ready?

Three properties. It authenticates each user individually rather than through a shared key, its permissions can be scoped so an agent reaches only what that person should, and every call is recorded with the identity behind it. Tool count is a much weaker signal than any of these.

### Should we run MCP servers ourselves or use hosted ones?

Hosted is the default for well-known SaaS systems, since the maintenance is real and continuous. Self-host when the system is internal, when data cannot leave your infrastructure, or when the server needs network access to something private.

### How many MCP servers should we start with?

Two or three, chosen by how many people they unblock rather than by how interesting they are. A Slack and GitHub pair covers most engineering work. Adding twenty at once mostly produces tool lists so long they degrade model tool selection.

### Do too many connected tools hurt agent performance?

Yes. Every tool description is read on each request, which costs tokens and makes selection harder as the list grows. Scoping tools by role solves both problems, which is one of the practical reasons to route through a gateway.

### Can we connect internal systems that have no public MCP server?

Yes, by wrapping the internal API in a custom server. This is common and is the point at which running everything behind one gateway pays off, since the internal server then inherits the same authentication, policy, and logging as the rest.

## Sources

1. [Model Context Protocol specification](https://modelcontextprotocol.io)
2. [Metorial MCP server index](https://github.com/metorial/mcp-index)
3. [Metorial MCP containers](https://github.com/metorial/mcp-containers)
4. [Metorial integrations catalog](https://metorial.com/integrations)

---

# Zapier MCP Alternatives for Teams That Outgrew It

> **Answer.** Teams outgrow Zapier MCP over three things: actions run as one shared connection rather than as each user, the audit record is built for automation runs rather than agent sessions, and per-task pricing scales badly when an agent makes many calls per request. Metorial, Composio, Pipedream Connect, and self-hosting are the usual replacements, chosen by which of those three is binding.

- Question: Zapier MCP alternatives
- Canonical: https://metorial.com/answers/zapier-mcp-alternatives
- Last updated: 2026-08-25
- Reviewed by: Karim Rahme, Metorial

---

Zapier MCP is genuinely the fastest way to get an agent acting against apps you already connected. The reasons teams leave are structural rather than quality problems, and they appear at the same three points for almost everyone.

| If you outgrew Zapier MCP because of | Look at |
| --- | --- |
| Actions running as a shared connection, not as each user | Metorial or Arcade.dev |
| An audit trail a security review will not accept | Metorial or Runlayer |
| Per-task pricing against agent call volume | Metorial or self-hosting |
| Needing self-hosting or on-prem | Metorial |
| Wanting more developer-facing connectors | Composio |
| Keeping a low-code builder | Pipedream Connect |

## Why does per-user identity matter here?

Zapier's model was built for automation, where a workflow runs under an account connection and that is correct: the workflow is the actor.

Agents break that assumption. When an agent acts on behalf of a person, the right permission boundary is that person's, not the account's. Under a shared connection, an agent helping someone in support can reach every record the connection can reach, and the log shows the connection rather than the person. That is usually the specific finding that ends a security review.

## Why does pricing behave differently for agents?

A scheduled automation runs a predictable number of times, which is exactly what per-task pricing is designed for.

An agent may call four tools to answer one question, and a busy team may ask hundreds of questions a day. Cost then tracks conversation volume, which is both higher and far less predictable than workflow count. This is not a pricing flaw so much as a mismatch between a unit designed for automations and a workload that is not one.

## The alternatives

### Metorial: per-user identity and agent-shaped records

**Best for:** Teams that need each person's agent to act as that person, with a record to match.

[Metorial](https://metorial.com/) addresses all three exit reasons. Employees sign in through your identity provider and each call runs under their own OAuth credentials, so the permission boundary is the person's. [Tracing](https://metorial.com/tracing) records sessions with arguments, results, and identity, which is the artifact a review asks for. [Access control](https://metorial.com/access-control) binds tools to roles and groups. [Pricing](https://metorial.com/pricing) is per tool call with a free Dev tier of 500K calls, and on-prem is available.

For teams that liked how Zapier let non-engineers build things, [Agent Skills](https://metorial.com/skills) is the nearest equivalent: a packaged procedure someone in operations can write and share without a repository.

**Where it falls short.** Metorial has no trigger-based workflow engine. If you need "when a row is added, do this" on a schedule with no agent involved, Zapier is still the right tool and you should keep it for that.

### Composio: developer-facing connector breadth

**Best for:** Developers who want many connectors and managed authentication quickly.

A broad catalog with a usage-based free tier, aimed at developers rather than at operations teams.

**Where it falls short.** Cloud only, basic per-user isolation, limited observability. Covered in [Composio alternatives](https://metorial.com/answers/composio-alternatives).

### Pipedream Connect: keeping a low-code builder

**Best for:** Teams who want to keep visual workflow building alongside agent access.

The closest in shape to Zapier, so the mental model transfers with the least retraining.

**Where it falls short.** Governance and audit depth trail the purpose-built gateways, so if the audit trail is why you are leaving, this may not fix it.

### Self-hosting MCP servers

**Best for:** A small number of integrations owned by engineers.

No per-task cost at all, and [mcp-containers](https://github.com/metorial/mcp-containers) covers the packaging.

**Where it falls short.** You take on token refresh, per-user credential isolation, and audit logging, which is most of what you were paying for.

## Who should pick what?

- **Stay on Zapier MCP** if a shared connection is acceptable and your call volume is low. It is the least work by a wide margin.
- **Metorial** if per-user identity, audit records, or call-volume pricing is the blocker.
- **Composio** if you want developer-facing breadth and are still prototyping.
- **Pipedream Connect** if keeping a visual builder matters more than audit depth.
- **Self-hosting** if the scope is two or three integrations and engineering owns them.
- **Both** is a legitimate answer: Zapier for scheduled automation, a gateway for agent tool access.

## Next step

Connect the same app through a gateway and compare what the session record contains:

```sh
npm install -g @metorial/cli
metorial login
metorial integrations setup slack
metorial sessions list
```

[Pricing](https://metorial.com/pricing) has the per-call model, and [What is an MCP gateway?](https://metorial.com/answers/what-is-an-mcp-gateway) covers what the layer does.

## Frequently asked questions

### What is Zapier MCP?

An MCP endpoint exposing the actions in your Zapier account so an AI client can invoke them. It is the fastest path from an existing Zapier setup to an agent that can act, because the connections and app coverage already exist.

### Why do teams move off Zapier MCP?

Actions typically run under one shared account connection rather than as the individual user, so an agent can reach whatever that connection can. Combined with per-task pricing and an audit trail designed for automation runs, this becomes limiting once agents are used broadly.

### Is Zapier MCP secure enough for a company rollout?

It depends on whether your reviewer accepts shared connections. If they require that each call runs under the acting person's own credentials and appears in a log naming that identity, a purpose-built gateway is a better fit.

### What is the cost difference?

Zapier charges per task, which suits scheduled automations that run a predictable number of times. An agent may make several tool calls to answer one question, so cost tracks conversation volume rather than workflow count. Gateways priced per tool call or per seat model that better.

### Can I keep Zapier for automation and use something else for agents?

Yes, and it is a common split. Zapier keeps the scheduled and trigger-based workflows it is good at, while agent tool access moves to a gateway with per-user identity and session records. The two do not conflict.

## Sources

1. [Zapier MCP](https://zapier.com/mcp)
2. [Model Context Protocol specification](https://modelcontextprotocol.io)
3. [Metorial pricing](https://metorial.com/pricing)

---

# Arcade.dev Alternatives: 6 Enterprise AI Gateways Compared

> **Answer.** Arcade.dev is specialized in agent authorization, so the alternatives split by what you need instead. Metorial for getting AI past engineering with self-hosting and Skills, Runlayer for externally audited inspection, Barndoor for cost, MintMCP for speed of rollout, Composio for breadth of connectors, and self-hosting when the scope is one or two integrations.

- Question: Arcade.dev alternatives
- Canonical: https://metorial.com/answers/arcade-dev-alternatives
- Last updated: 2026-08-25
- Reviewed by: Karim Rahme, Metorial

---

Arcade.dev is narrow on purpose. It answers one question well: can this agent exceed the permissions of the person it is acting for? If that is your entire requirement, the alternatives below will mostly look like more product than you need. If it is one requirement among several, the gap shows quickly.

| If your actual requirement is | Look at |
| --- | --- |
| Non-engineers using AI safely | Metorial |
| Independent audit of every tool call | Runlayer |
| Reducing token spend on tool use | Barndoor |
| A governed rollout in days | MintMCP |
| The widest connector catalog | Composio or Metorial |
| Self-hosting or on-prem | Metorial |

## What does Arcade actually cover?

Per-user authorization on the call path, with each attempt logged whether it succeeds or is denied. It raised $60M in a Series A, on $72M total, which is a reasonable signal that the authorization framing found buyers.

What it does not attempt: cost optimization, discovery of unapproved servers already in use, and any surface for people who do not write code. Those are not gaps in execution, they are scope decisions.

## The alternatives

### Metorial: getting AI past engineering

**Best for:** Companies where the constraint is adoption outside the engineering team.

[Metorial](https://metorial.com/) covers the authorization requirement through SSO-bound [access control](https://metorial.com/access-control) and per-user OAuth, then adds the layers Arcade leaves out. [Agent Skills](https://metorial.com/skills) let a support lead package a procedure and share it with their team without a repository. [Magic MCP](https://metorial.com/magic-mcp) gives one endpoint that works the same across Claude, Cursor, Codex, and Copilot. [Protoguard](https://metorial.com/protoguard) checks calls for prompt injection, [Tracing](https://metorial.com/tracing) records sessions, and the platform is open core with on-prem deployment.

**Where it falls short.** For a security-only rollout that never leaves engineering, Arcade goes deeper on the authorization model itself, and Metorial's breadth is overhead you will not use. Detail in [Metorial vs Arcade.dev](https://metorial.com/comparisons/metorial-vs-arcade-dev).

### Runlayer: externally verified inspection

**Best for:** Reviews that require validation from someone other than the vendor.

Runlayer inspects calls in both directions and produces tamper-evident logs, backed by AARM Extended Conformance R1 through R9 and MCP's lead creator on its advisory board. $41M raised.

**Where it falls short.** Like Arcade, it is a security product rather than an adoption one. See [Metorial vs Runlayer](https://metorial.com/comparisons/metorial-vs-runlayer).

### Barndoor: cost control

**Best for:** Teams where the AI bill, not the permission model, is the problem.

The ToolIQ router avoids re-sending every tool description on every request, which Barndoor reports cuts token use and processing cost per query by up to 95%. $13.6M raised.

**Where it falls short.** No Skills layer, no non-engineering surface, and less authorization depth than Arcade.

### MintMCP: speed of rollout

**Best for:** Bringing a department online quickly with role-scoped access.

Role-specific endpoint URLs carrying only the tools that role should reach, which makes the first governed deployment fast.

**Where it falls short.** Shallower inspection than Runlayer or Arcade, and no shared procedure layer.

### Composio: breadth of connectors

**Best for:** Prototypes that need many integrations working today.

Strong managed authentication and a broad catalog, with a usage-based free tier that suits experimentation.

**Where it falls short.** Cloud only, basic per-user isolation, and limited observability. Those are the reasons teams leave, covered in [Composio alternatives](https://metorial.com/answers/composio-alternatives).

### Self-hosting

**Best for:** One or two integrations owned by engineers with no compliance requirement.

Full control, no license cost, and [mcp-containers](https://github.com/metorial/mcp-containers) removes most of the packaging work.

**Where it falls short.** You build the authorization model Arcade sells, plus token refresh, isolation, and an audit log. Reasonable for two integrations, not for twenty.

## Who should pick what?

- **Stay with Arcade.dev** if authorization is the requirement and the users are engineers.
- **Metorial** if AI has to reach people outside engineering, or you need on-prem.
- **Runlayer** if an external auditor's sign-off is what unblocks the project.
- **Barndoor** if spend is the binding constraint.
- **MintMCP** if you need a governed rollout in days.
- **Composio** if you are still prototyping and want breadth.
- **Self-hosting** if the scope is genuinely small.

## Next step

Compare the access model directly by connecting an integration and granting it to a group:

```sh
npm install -g @metorial/cli
metorial login
metorial integrations setup salesforce
```

[Access control](https://metorial.com/access-control) covers the permission model, and [Metorial vs Arcade.dev](https://metorial.com/comparisons/metorial-vs-arcade-dev) has the head-to-head.

## Frequently asked questions

### What does Arcade.dev do well?

Agent authorization. Every tool call is narrowed to the permissions of the user the agent acts for, and the attempt is recorded whether or not it succeeds. If your requirement is proving an agent cannot exceed its user, it is one of the strongest implementations available.

### Why would a team look for an Arcade.dev alternative?

Usually because their problem is not only authorization. Teams that need non-engineers to use AI, want to reduce token spend, or need a shared procedure layer find Arcade deliberately narrow, since it does not attempt those.

### Which alternative matches Arcade on security?

Runlayer is closest on inspection depth and has gone further on external validation with AARM Extended Conformance. Metorial covers SOC 2 Type II, GDPR, and on-prem with per-user identity, which passes most reviews without being as specialized.

### Is Arcade.dev open source?

Arcade offers a tool SDK and a self-hostable engine, but it is not open core in the way Metorial is. If reading and modifying the platform itself matters to you, check the license terms against your requirements before committing.

### Can I run more than one of these at once?

Technically yes, and some teams do run a cost router in front of a gateway. It doubles the operational surface and splits the audit trail across two systems, so it is worth confirming that one product cannot cover both needs first.

## Sources

1. [Arcade.dev](https://www.arcade.dev)
2. [Arcade Raises $60M to Become the Secure Action Layer Behind Every Production AI Agent](https://www.businesswire.com/news/home/20260615229631/en/Arcade-Raises-$60M-to-Become-the-Secure-Action-Layer-Behind-Every-Production-AI-Agent)
3. [Runlayer Raises $30 Million in Series A Funding (SecurityWeek)](https://www.securityweek.com/runlayer-raises-30-million-in-series-a-funding/)
4. [Metorial security and compliance](https://metorial.com/security)

---

# Composio Alternatives: 7 MCP Platforms Compared (2026)

> **Answer.** The strongest Composio alternatives are Metorial for open-source MCP infrastructure with self-hosting, Arcade.dev for agent authorization, Runlayer for externally audited security, Barndoor for cutting AI cost, MintMCP for the fastest setup, Pipedream Connect for low-code workflows, and self-hosting when you only need one or two integrations. Most teams leave Composio for self-hosting, per-user isolation, or observability.

- Question: Composio alternatives
- Canonical: https://metorial.com/answers/composio-alternatives
- Last updated: 2026-08-25
- Reviewed by: Karim Rahme, Metorial

---

Composio is a competent action layer for agents, and teams that need broad connectivity fast are usually well served by it. The alternatives below exist because it stops short in three specific places: it is cloud-only, per-user isolation is basic, and observability thins out exactly when a tool call fails in production.

| If you are leaving Composio because of | Look at |
| --- | --- |
| No self-hosting or on-prem option | Metorial, or self-hosting community servers |
| Each end user must act as themselves | Metorial or Arcade.dev |
| A security review you cannot pass | Runlayer or Arcade.dev |
| AI spend | Barndoor |
| Needing something compliant running this month | MintMCP |
| Non-engineers needing to build workflows | Metorial or Pipedream Connect |

## What should you compare?

Vendor homepages converge on the same claims, so these are the five dimensions where the products actually differ: deployment model, whether credentials are per user or shared, what the audit record contains, who can use it besides engineers, and how the pricing scales with tool calls.

## The alternatives

### Metorial: open-source MCP infrastructure with self-hosting

**Best for:** Teams that need self-hosting, per-user isolation, and records that survive a security review.

[Metorial](https://metorial.com/) is the closest direct replacement, and the one that addresses all three of Composio's common exit reasons. It is open core under the FSL license, deployable on-prem, and built so each end user authenticates as themselves rather than sharing a key. [Tracing](https://metorial.com/tracing) records every session with arguments, results, and the acting identity. The catalog is [1,000+ integrations](https://metorial.com/integrations), and custom or remote servers register alongside them.

The layer Composio has no equivalent for is [Agent Skills](https://metorial.com/skills): packaged procedures a non-engineer can write and share without a repository.

**Where it falls short.** For a rollout that stays inside engineering and only needs authorization depth, Arcade.dev is more specialized. Metorial is also a broader platform than some teams want; if you need one integration and nothing else, it is more than the job requires. The head-to-head detail is in [Metorial vs Composio](https://metorial.com/comparisons/metorial-vs-composio).

### Arcade.dev: agent authorization

**Best for:** Proving an agent cannot exceed the permissions of the user it acts for.

Arcade builds a secure action layer where every call is narrowed to the acting user's own permissions and the attempt is logged either way. If your security requirement is specifically about permission boundaries, this is one of the strongest implementations available. It has raised $72M in total.

**Where it falls short.** No cost control, no discovery of unapproved servers, and nothing aimed at non-engineers. See [Metorial vs Arcade.dev](https://metorial.com/comparisons/metorial-vs-arcade-dev).

### Runlayer: externally verified security

**Best for:** Security teams that want independent validation rather than vendor claims.

Runlayer inspects every tool call passing between clients and servers and produces tamper-evident logs. Its credibility is external: AARM Extended Conformance R1 through R9, and MCP's lead creator on its advisory board. It has raised $41M.

**Where it falls short.** It is not built to get the rest of the company using AI, and does not try to be. See [Metorial vs Runlayer](https://metorial.com/comparisons/metorial-vs-runlayer).

### Barndoor: cutting AI cost

**Best for:** Teams whose AI bill is the constraint.

Barndoor's ToolIQ router addresses a specific waste: a model connected to hundreds of tools reads every tool description on every request and you pay for those tokens each time. Barndoor reports up to 95% reduction in token use and processing cost per query. It raised $13.6M.

**Where it falls short.** No shared workflow layer and nothing for non-engineering teams.

### MintMCP: fastest setup

**Best for:** Showing a governed setup to a security reviewer next week.

Each role gets an endpoint URL carrying only the tools that role should reach, so bringing a department online is closer to one configuration step than a project.

**Where it falls short.** No shared Skills layer, no cost optimization, and less depth on inspection than Runlayer or Arcade.

### Pipedream Connect: low-code workflows

**Best for:** Teams already building in a low-code tool who want agent access alongside it.

Pipedream comes at this from workflow automation rather than agent infrastructure, which suits teams whose processes already live there.

**Where it falls short.** Governance and audit depth are well behind the purpose-built gateways, and the model is workflow-first rather than agent-first.

### Self-hosting community MCP servers

**Best for:** One or two integrations, owned by engineers, with no compliance requirement.

No license cost, complete control. Catalogs such as [mcp-index](https://github.com/metorial/mcp-index) and prebuilt [mcp-containers](https://github.com/metorial/mcp-containers) make the starting point easy.

**Where it falls short.** You own per-provider token refresh, credential isolation, policy evaluation, and an audit log that holds up under review. That is the work a gateway exists to absorb, and it grows with every integration.

## Who should pick what?

- **Metorial** if self-hosting, per-user identity, or getting AI past engineering is the blocker.
- **Arcade.dev** if you must prove agents cannot exceed their user's permissions.
- **Runlayer** if an external auditor's opinion is what unblocks you.
- **Barndoor** if spend is the constraint.
- **MintMCP** if you need something compliant running immediately.
- **Pipedream Connect** if your processes already live in a low-code tool.
- **Self-hosting** if the scope is small and engineering owns it.
- **Composio** if broad connectivity is genuinely all you need. It is a reasonable answer to that question.

## Next step

Connect an integration and compare the setup against your current one:

```sh
npm install -g @metorial/cli
metorial login
metorial integrations setup github
```

The [Dev plan](https://metorial.com/pricing) is free, and [Metorial vs Composio](https://metorial.com/comparisons/metorial-vs-composio) has the feature-level detail.

## Frequently asked questions

### Why do teams look for a Composio alternative?

The three reasons that come up most are the lack of a self-hosting option, limited per-user isolation when each end user must act as themselves, and thin observability once tool calls fail in production. Teams that only need broad connectivity usually stay.

### Is there an open-source alternative to Composio?

Metorial is open core, published under the FSL license, and can be self-hosted or run on-prem. You can also assemble your own layer from community MCP servers, though you then own credential handling, access control, and audit logging yourself.

### Which Composio alternative is best for enterprise security reviews?

Runlayer has gone furthest on external validation, and Arcade.dev has the most specialized agent authorization model. Metorial is SOC 2 Type II and GDPR compliant with on-prem deployment, which covers most reviews without being the most specialized on either axis.

### Can I migrate from Composio without rewriting my agent?

Largely, if you are already calling tools over MCP, because the protocol is the same on both sides. The work is re-establishing authentication connections and re-pointing clients at the new endpoint, not rewriting agent logic.

### What is the cheapest Composio alternative?

Self-hosting community MCP servers has no license cost but real operational cost. Among managed options, Metorial has a free Dev tier with 500K tool calls, and Barndoor competes specifically on reducing the token spend of tool use.

## Sources

1. [Composio](https://composio.dev)
2. [Arcade Raises $60M Series A (Businesswire)](https://www.businesswire.com/news/home/20260615229631/en/Arcade-Raises-$60M-to-Become-the-Secure-Action-Layer-Behind-Every-Production-AI-Agent)
3. [Runlayer Raises $30 Million in Series A Funding (SecurityWeek)](https://www.securityweek.com/runlayer-raises-30-million-in-series-a-funding/)
4. [Barndoor AI Raises $13.6M in Series Seed (PR Newswire)](https://www.prnewswire.com/news-releases/barndoor-ai-raises-13-6m-in-series-seed-to-deliver-the-first-control-plane-for-agentic-ai-workforces-302459846.html)
5. [Metorial open source core on GitHub](https://github.com/metorial/metorial)

---

# Are MCP Servers Secure? Risks, Attacks, and Controls

> **Answer.** MCP is a transport and discovery protocol with no built-in security model, so an MCP server is only as secure as the credentials, isolation, and logging around it. The four risks that matter in practice are prompt injection, over-scoped credentials, unvetted third-party servers, and missing audit records. All four are addressable, but not by the protocol.

- Question: are MCP servers secure
- Canonical: https://metorial.com/answers/are-mcp-servers-secure
- Last updated: 2026-08-25
- Reviewed by: Karim Rahme, Metorial

---

The question is usually asked about the protocol, but the protocol is not where the risk is. MCP describes how a tool is advertised and called. Everything that makes a deployment safe or unsafe sits around it.

| Risk | Control that addresses it |
| --- | --- |
| Prompt injection through tool output | Inspect calls before execution; keep destructive tools behind approval |
| Over-scoped or shared credentials | Per-user OAuth, narrow scopes, no shared keys |
| Unvetted third-party servers | Run them isolated, with their own network and credential boundary |
| No record of what an agent did | Log every call with arguments, result, and acting identity |
| Data leaving your infrastructure | Self-hosted or on-prem deployment |

## What does the MCP specification actually cover?

Tool description, discovery, invocation, and transport. It does not define authentication between a client and a server, an authorization model, or an audit requirement. Recent revisions added security guidance, but guidance is not enforcement.

This is a reasonable design for a protocol. It becomes a problem when teams read "standard" as "safe" and connect a server holding production credentials.

## What is the biggest practical risk?

Prompt injection, because it turns a data-access problem into an action problem.

A model reads content from somewhere: an issue, an email, a web page, a document. If that content contains instructions, the model may follow them, since it has no reliable way to separate data it was asked to process from instructions it was asked to obey. With no tools attached, the worst case is a bad answer. With tools attached, the model can act on the injected instruction using real credentials.

The mitigation is layered: inspect tool calls before they execute, keep the credential scope narrow enough that a successful injection has a small blast radius, and require approval for destructive actions.

## What goes wrong with credentials?

The common failure is mundane. Someone pastes an API key into a config file to get a server working, it works, and a teammate copies it. Months later nobody knows who created the key, what it can reach, or when it expires.

Two properties fix this. Credentials should be per user, so a call is limited to what that person could already do. And they should never be handled by the person, so there is nothing to paste or copy.

This is also what makes an incident answerable. If an agent deletes the wrong record, the first question is whose access it used. A shared key on a laptop has no answer.

## How risky are third-party MCP servers?

A community server is a dependency that will hold credentials to one of your systems. That deserves the scrutiny you would give any such dependency: who maintains it, whether you can read the source, and what scopes it asks for.

Supply chain risk here is real rather than theoretical. We wrote up one incident in [What the Composio security incident says about MCP security](https://metorial.com/blog/composio-security-incident-mcp-security).

The practical answer is isolation. Run third-party servers in their own environment with their own network boundary and narrow scopes, so a compromised one cannot reach beyond the system it serves.

## What does a secure deployment look like?

- Employees authenticate through your existing identity provider; nobody handles an API key by hand.
- Tool access is bound to roles and groups, granted on the first day and removed on the last.
- Every call is inspected for injection before it executes.
- Every session is recorded with arguments, results, and the acting identity.
- Third-party servers run isolated, with their own networking and firewall rules.
- The deployment model matches your data rules, up to on-prem if required.

## How does Metorial address this?

[Metorial](https://metorial.com/) supplies those controls as the default rather than as configuration. Employees sign in through SSO and never touch a key. [Access control](https://metorial.com/access-control) binds tools to roles. [Protoguard](https://metorial.com/protoguard) checks calls for prompt injection before execution. [Tracing](https://metorial.com/tracing) records every session with the identity behind it. Servers run in isolated enclaves with their own networking, and the platform is [SOC 2 Type II and GDPR compliant](https://metorial.com/security) with on-prem available.

Where it is weaker: if you need certification beyond SOC 2 Type II, some competitors have gone further with third-party conformance specifications, and we say so in [Best Enterprise MCP Gateways](https://metorial.com/comparisons/best-enterprise-ai-gateways-2026). Protoguard also reduces prompt injection risk rather than eliminating it, which no product can honestly claim to do.

## Next step

Review what a deployment records and restricts before connecting production credentials. [Metorial security](https://metorial.com/security) covers the compliance posture, and [MCP role-based access](https://metorial.com/blog/mcp-role-based-access) covers how to model permissions.

To inspect what an agent actually sent, session records are available through the API:

```sh
metorial sessions list
```

## Frequently asked questions

### Is MCP inherently insecure?

No, but it is not secure by default either. The specification covers how tools are described and invoked, not who may invoke them or under whose credentials. Security comes from the layer you run servers behind, which is why gateways exist.

### What is prompt injection in an MCP context?

Content the model reads, such as an issue body or an email, containing instructions the model follows as if they came from the user. It matters more with tools attached, because a model that can act on the injected instruction can exfiltrate or destroy data.

### Is it safe to use community MCP servers?

Treat one like any dependency that will hold your credentials. Check who maintains it, whether the source is available, and what scopes it requests. Prefer running it in isolation with narrow scopes over installing it on a laptop with a broad token.

### Can an MCP server see all of my data?

It sees whatever the credentials you gave it can reach, which is why over-scoped tokens are the most common real problem. A server given an admin key has admin access. Per-user OAuth limits each call to what that specific person could already do.

### What should a security team require before approving MCP?

Per-user credentials rather than shared keys, tool access bound to roles, a log naming the identity behind every call, isolation for third-party servers, and a deployment model that meets your data residency rules.

## Sources

1. [Model Context Protocol: security considerations](https://modelcontextprotocol.io/specification/draft/basic/security_best_practices)
2. [OWASP Top 10 for Large Language Model Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/)
3. [Metorial security and compliance](https://metorial.com/security)

---

# Skills vs MCP Tools: When to Use Which

> **Answer.** An MCP tool is a single callable action, like creating an issue or sending a message. A Skill is a packaged procedure that tells an agent which tools to use, in what order, and under what constraints. Tools are the verbs; a Skill is the instruction that uses them. You need both, and they are not alternatives.

- Question: skills vs MCP tools
- Canonical: https://metorial.com/answers/skills-vs-mcp-tools
- Last updated: 2026-08-25
- Reviewed by: Karim Rahme, Metorial

---

The confusion comes from both being described as "what an agent can do". One is a capability, the other is a procedure that uses capabilities.

| If you want an agent to | You need |
| --- | --- |
| Create a Linear issue | An MCP tool |
| Triage a bug report the way your team triages it | A Skill that uses several tools |
| Read a Salesforce record | An MCP tool |
| Run your team's refund process end to end | A Skill |
| Do the same multi-step job identically for everyone | A Skill, shared to a group |

## What is an MCP tool?

A tool is one action a server exposes: a name, a description, and a typed input schema. `create_issue` takes a title and a body and creates an issue. It has no opinion about when it should be called or what should happen next.

Tools are the atoms. A model given twenty tools can combine them, but it will combine them slightly differently every time, because nothing tells it what your team's process actually is.

## What is a Skill?

A Skill packages a procedure: the instructions for a job, plus the specific tools that job needs. "Triage an inbound bug report" is a Skill. It says which fields to check, which tools to call, when to escalate, and what to leave alone.

The important property is that it is shareable. One person writes the procedure once, and everyone who should have it gets the same behavior, rather than each person re-explaining the job to their own chat window.

## When should you use a tool versus a Skill?

Use a tool when the action is atomic and the model can reasonably decide when to call it.

Use a Skill when the job has steps, when the order matters, when there are rules about what not to do, or when you need two people to get the same result. Consistency is the real signal: if it matters that everyone does it the same way, it is a Skill.

## Why does the distinction matter for rollouts?

Because they fail differently.

Tool problems are access problems. Someone cannot reach the system, or the credentials are wrong, or nobody knows which agent did what. Those are solved by a [gateway](https://metorial.com/answers/what-is-an-mcp-gateway).

Skill problems are distribution problems. The procedure exists in one person's head or one person's chat history, and there is no way to hand it to the rest of the team. When Skills live in a code repository, non-engineers cannot contribute, which quietly caps AI adoption at the engineering department. We wrote about that in [AI skills without GitHub](https://metorial.com/blog/ai-skills-without-github).

## How does Metorial handle both?

[Metorial](https://metorial.com/) treats them as separate layers on purpose. [Integrations](https://metorial.com/integrations) supply the tools, with per-user OAuth and [access control](https://metorial.com/access-control) deciding who reaches what. [Agent Skills](https://metorial.com/skills) sit above them, so a support lead can write a refund triage procedure in the morning and have the team using it that afternoon, without touching a repository. [Tracing](https://metorial.com/tracing) records both the Skill run and each underlying tool call.

Where this is not the right fit: if your Skills are authored exclusively by engineers who already live in Git and review each other's changes, a repository-based workflow gives you code review for free, and Metorial's advantage mostly disappears.

## Next step

List the tools an integration exposes before writing a Skill against them:

```sh
metorial integrations tools support-github
```

Then see [Agent Skills](https://metorial.com/skills) for authoring and sharing, or the [skills API](https://metorial.com/api/skills) to manage them programmatically.

## Frequently asked questions

### Can a Skill work without MCP tools?

A Skill made only of instructions works, but it can only change how the model reasons or writes. To do anything in an external system it needs tools. In practice most useful Skills bundle instructions with the specific tools the procedure requires.

### Do I need to write code to create a Skill?

Not with Metorial. A Skill is written as instructions plus a set of tools, so someone in support or operations can create one without a GitHub account or a pull request. That is the main difference from repository-based approaches.

### How is a Skill different from a system prompt?

A system prompt applies to every request in a session. A Skill is scoped, shareable, and versioned: it applies to one procedure, carries its own tool access, and can be granted to a group rather than pasted between people.

### Who should own Skills, engineering or the team using them?

The team doing the work, in most cases. They know the procedure, and a Skill they can edit stays current. Engineering usually owns the underlying tools and the access policy, which is a cleaner split than one team owning both.

### What happens when a Skill needs a tool the user cannot access?

Access control still applies. A Skill does not widen permissions, so a user without access to a tool cannot reach it through a Skill. The Skill is a procedure, not an escalation path.

## Sources

1. [Model Context Protocol: tools](https://modelcontextprotocol.io/docs/concepts/tools)
2. [Metorial Agent Skills](https://metorial.com/skills)
3. [Metorial API reference: skills](https://metorial.com/api/skills)

---

# MCP vs API: What's the Difference?

> **Answer.** An API is a contract between two pieces of software, invoked by code someone wrote in advance. MCP is a protocol that lets a model discover the available tools at runtime and choose one, without anyone writing per-tool integration code. MCP does not replace APIs, it wraps them so a model can use them.

- Question: MCP vs API
- Canonical: https://metorial.com/answers/mcp-vs-api
- Last updated: 2026-08-25
- Reviewed by: Karim Rahme, Metorial

---

The two are not alternatives. MCP is a layer above APIs that makes them usable by a model that decides at runtime what to call.

| Criteria | MCP | A direct API |
| --- | --- | --- |
| Who decides what to call | The model, at runtime | Your code, written in advance |
| Discovery | Tools listed by the server | Read the docs, write a client |
| Adding a capability | Register a server | Write and deploy new code |
| Reuse across AI clients | Same server, every client | Reimplement per client |
| Best for | Agent tool use | Deterministic backend calls |

## What is an API in this context?

An API is a contract: named endpoints, typed inputs, defined responses. To use one you read its documentation, write a client, and deploy that client. The set of calls your software can make is fixed when you ship it.

That model is correct and efficient when your code knows what it needs. It breaks down when the caller is a language model that will decide, mid-conversation, that it needs to search Slack.

## What is MCP?

The [Model Context Protocol](https://modelcontextprotocol.io) is an open standard for exposing tools to a model. An MCP server advertises the tools it offers, each with a name, a description, and a typed input schema. A client connects, asks what is available, and passes those descriptions to the model. The model picks one and the client invokes it.

The shift is that integration moves out of your application. The server describes itself, and any MCP-compatible client can use it without code written specifically for it.

## How is MCP different from function calling?

Function calling is the model capability of emitting a structured call against a schema you supply. MCP is the standard for where those schemas come from and how the call is executed.

Without MCP, you define each function in your application and maintain it there. With MCP, the tool lives in a server outside your application, and every client that speaks the protocol gets it. They work together: MCP supplies the tool definitions that function calling consumes.

## When should you use each?

Use a direct API client when the call path is deterministic. A nightly job that syncs records has no reason to route through a protocol built for runtime choice.

Use MCP when the model chooses the tool, when several AI clients need the same integration, or when you want to add capabilities without shipping application code.

Most production systems run both: MCP for what agents reach for, direct clients for the paths your own code owns.

## What does MCP not solve?

This is the part most comparisons omit. MCP standardizes discovery and invocation. It says nothing about:

- **Whose credentials the call runs under.** The protocol has no opinion on per-user OAuth or token refresh.
- **Who is allowed to call what.** There is no permission model in the spec.
- **Where the record goes.** There is no audit requirement.
- **Where servers run.** Hosting, isolation, and networking are yours.

Those four gaps are the reason [MCP gateways](https://metorial.com/answers/what-is-an-mcp-gateway) exist. If you are running MCP for one developer, you will not notice them. Running it for a company, they are the whole problem.

## How does Metorial relate to MCP?

[Metorial](https://metorial.com/) is MCP infrastructure rather than another protocol. It runs the servers, handles per-user OAuth so an agent acts as the person it is working for, applies [access control](https://metorial.com/access-control) to decide which tools each user reaches, and records every call in [Tracing](https://metorial.com/tracing). The catalog is [1,000+ integrations](https://metorial.com/integrations), and custom or remote servers register alongside them.

Where a direct API still wins: a single integration your team already maintains, with one fixed call path and no plans to add more. In that case MCP is machinery you do not need yet.

## Next step

Wrap your first API as an MCP tool, or connect one of the existing ones:

```sh
npm install -g @metorial/cli
metorial integrations setup github
metorial integrations tools support-github
```

For custom servers, see [Custom servers: Overview](https://metorial.com/docs/custom-servers-overview). The [OpenAPI specification](https://metorial.com/openapi.json) describes the platform API itself.

## Frequently asked questions

### Does MCP replace REST APIs?

No. Almost every MCP server calls a REST API underneath. MCP adds a discovery and invocation layer a model can use, so the same API becomes callable without writing a client for it. The API stays the system of record.

### Is MCP just function calling with extra steps?

Function calling is a model capability: the model emits a structured call. MCP is the transport and discovery standard around it, so tools live outside your application and any MCP-compatible client can use them. They compose rather than compete.

### Is MCP slower than calling an API directly?

Slightly, since the call passes through a server that then calls the API. In practice the overhead is small next to model inference and the upstream request, and it buys runtime discovery and one integration surface across every client.

### When should I call an API directly instead of using MCP?

When the call path is fixed and your code, not a model, decides what to invoke. Deterministic backend work is better served by a normal client. Use MCP when the model chooses the tool at runtime or when several AI clients need the same integration.

### Can I expose my existing internal API over MCP?

Yes. Wrapping an internal API in an MCP server is the common path, and it means agents reach it through the same access control and logging as every other tool. Metorial supports custom and remote providers for exactly this.

## Sources

1. [Model Context Protocol specification](https://modelcontextprotocol.io)
2. [MCP architecture and transports](https://modelcontextprotocol.io/docs/concepts/architecture)
3. [Metorial documentation: Integrations overview](https://metorial.com/docs/integrations-overview)

---

# What Is an MCP Gateway? Definition and When You Need One

> **Answer.** An MCP gateway is a single control point that sits between your AI clients and every MCP server they call. It handles authentication, access control, and logging once, centrally, instead of once per tool and per client. You need one when more than one team or more than one AI client needs the same integrations.

- Question: what is an MCP gateway
- Canonical: https://metorial.com/answers/what-is-an-mcp-gateway
- Last updated: 2026-08-25
- Reviewed by: Karim Rahme, Metorial

---

The [Model Context Protocol](https://modelcontextprotocol.io) standardizes how an AI client calls a tool. It does not say who is allowed to make the call, whose credentials it runs under, or where the record of it goes. A gateway is the layer that answers those three questions for every server at once.

| If your situation is | Then |
| --- | --- |
| One developer, one AI client, two or three MCP servers | You do not need a gateway. Configure the servers directly. |
| A team sharing servers, each on a different AI client | You need a gateway for one shared configuration. |
| Non-engineers need tool access | You need a gateway with identity-based access, not config files. |
| Security has to approve AI tool use | You need a gateway that records every call and who it ran as. |
| Data residency or on-prem requirements | You need a gateway you can self-host. |

## What does an MCP gateway actually do?

Four jobs, all of which you would otherwise build once per integration.

**Authentication.** Each MCP server needs credentials for the system behind it. A gateway runs the OAuth flow per user, stores and refreshes the tokens, and injects them at call time, so no API key ends up in a config file on a laptop.

**Access control.** Policies decide which users and which agents can reach which tools. Bound to your identity provider, this means a new hire gets the right tools on day one and loses them on their last, without anyone editing a server list.

**A stable endpoint.** Clients point at one URL instead of a list of servers. Adding a server or moving one does not require reconfiguring every client, and switching from Claude to Cursor does not mean rebuilding the setup.

**Records.** Every tool call is logged with its arguments, its result, and the identity it ran as. This is the artifact a security review asks for, and it is also what you read when an agent does the wrong thing.

## How is a gateway different from an MCP server?

An MCP server exposes one system: a GitHub server exposes issues and pull requests, a Salesforce server exposes records. A gateway sits above many servers and handles what all of them have in common.

The distinction matters because the two are often confused in vendor material. If a product connects to one system, it is a server. If it sits in front of servers and applies policy to them, it is a gateway.

## When do you actually need one?

The threshold is not a company size, it is a second of something. A second AI client, a second team, or a second person who needs the same integration.

Up to that point, direct configuration is genuinely simpler. Past it, every integration has to be set up once per person and per client, credentials get copied between people to save time, and no single place can answer which agent did what. Those three problems arrive together, and they are what a gateway exists to prevent.

## Can you build a gateway yourself?

Yes, and the first version is not hard. The cost is in what follows: token refresh for every provider, per-user credential isolation, policy evaluation on the call path, an audit log that holds up under review, and keeping pace with MCP as it changes.

Build it if agent infrastructure is your product. Buy it if agent infrastructure is what your product needs in order to work.

## What should you compare when picking one?

- **Deployment model.** Hosted, VPC, on-prem, or air-gapped. If you are in a regulated industry, this decides the shortlist before anything else does.
- **Identity integration.** Does it bind to your SSO and groups, or does it maintain its own user list that someone has to keep in sync?
- **Who can use it.** Engineers only, or can someone in support or operations get access without a code repository? This is the difference between AI reaching twenty people and two hundred.
- **What is recorded.** Whether the log captures arguments and results, and whether it names the user identity the call ran as.
- **Catalog.** How many integrations exist already, and how hard it is to add one that does not.

## Where does Metorial fit?

[Metorial](https://metorial.com/) is an MCP gateway built around the case where AI has to reach past engineering. Employees sign in through your existing identity provider and get the tools the company approved, with no API key to copy. [Magic MCP](https://metorial.com/magic-mcp) gives every integration one URL that works the same in Claude, Cursor, Codex, or Copilot. [Access control](https://metorial.com/access-control) binds tools to roles and groups, [Tracing](https://metorial.com/tracing) records every session, and [Protoguard](https://metorial.com/protoguard) checks calls for prompt injection. It is [SOC 2 Type II and GDPR compliant](https://metorial.com/security), open core, and available on-prem.

Where it is weaker: for a security-only rollout that never leaves engineering, a gateway specialized in agent authorization will go deeper on that one axis. If cutting model spend is the main goal, a cost-routing gateway will beat it on that number. We compare those tradeoffs honestly in [Best Enterprise MCP Gateways](https://metorial.com/comparisons/best-enterprise-ai-gateways-2026).

## Next step

Browse the [1,000+ integrations](https://metorial.com/integrations) available as MCP servers, or connect your first one from the command line:

```sh
npm install -g @metorial/cli
metorial login
metorial integrations setup github
```

The [Dev plan](https://metorial.com/pricing) is free and needs no sales conversation.

## Frequently asked questions

### Is an MCP gateway the same as an API gateway?

They solve the same class of problem at different layers. An API gateway fronts HTTP endpoints and routes by path and method. An MCP gateway fronts tools that a model chooses at runtime, so it also has to handle per-user credentials and record which identity a call ran as.

### Do I need an MCP gateway for a single AI client?

Usually not. One developer with one client and a few servers is better off configuring them directly. The gateway earns its place when a second client or a second person needs the same integrations, because that is when per-person setup and shared credentials start.

### Can an MCP gateway be self-hosted?

Depending on the vendor. Metorial is open core and can run on your own infrastructure or on-prem. If data residency is a hard requirement, confirm hosted, VPC, on-prem, and air-gapped options before shortlisting anything.

### Does an MCP gateway slow down tool calls?

It adds one network hop plus policy evaluation, typically a few milliseconds. That is small next to the model inference and the upstream API call in the same request, and it removes the per-client credential lookups a direct setup repeats.

### What happens to my existing MCP servers?

They keep working. A gateway registers servers you already run, including custom and remote ones, and puts authentication, policy, and logging in front of them. You do not rewrite a server to put it behind a gateway.

## Sources

1. [Model Context Protocol specification](https://modelcontextprotocol.io)
2. [Metorial documentation: Concepts, Providers](https://metorial.com/docs/concepts-providers)
3. [Metorial open source core on GitHub](https://github.com/metorial/metorial)