Reference · Central Gateway · 2 September 2026

One front door for every MCP server you did not write

The Gateway sits in front of the servers you already use — yours and third parties’ — and decides, per call, whether the identity behind the agent may make it. Its own 25 tools are all about that decision: registering assets, scoring their risk, authoring policy, and proving what happened. Read the docs home for transport and connection.

25Tools

10Policy inputs

6Outcomes

Policy inputs

Ten things a decision reads before it answers

This is the practical difference between an API gateway and this one: the acting human is part of the input, not just the calling service. Two people behind the same agent, calling the same tool with the same arguments, can legitimately get different answers.

user idWho is actually acting, not which service called.
rolesEntitlements carried from your identity provider.
departmentFinance may do things support may not.
teamFiner than department, for delegated ownership.
environmentDev, staging or production. A test must not act like prod.
target regionWhere the call lands, for residency rules.
asset labelsClassification on the thing being touched.
parametersThe actual argument values, not just the tool name.
PII presenceWhether personal data is in the payload at all.
credential modePer-user token or shared service credential — the two are not equivalent.

Enforcement outcomes

Six ways to answer, only one of which is a flat no

Outcome	What it does, and when you would use it
denial	The call does not reach the downstream server. Correct for operations that no agent should perform regardless of who asked.
redaction	The call proceeds with fields removed or masked. The usual answer when the work is legitimate but the payload carries more personal data than the task needs.
human approval	One named person must say yes before execution. The decision and the approver are recorded together.
quorum	More than one approver, so a single compromised account cannot authorise the action alone. Reserve it for the irreversible ones.
budget control	A spend or call ceiling enforced at the gateway rather than discovered on an invoice. See Setting Agent Spend Ceilings.
per-user OAuth / OIDC	The call executes under the acting human’s own token rather than a shared service account, so downstream systems see and log the real actor.

Tool surface

25 tools, and none of them do your work

Read the list and the product becomes obvious: register an asset, learn what it exposes, score it, route it, govern it, prove it. The Gateway never performs the business action itself — the server behind it does.

Assets & discovery · 6

register_gateway_asset
get_gateway_asset
list_gateway_assets
discover_asset_tools
test_gateway_asset_connection
build_capability_graph

Evaluation & risk · 4

evaluate_tool_call
score_tool_risk
normalize_tool_contract
analyze_change_impact

Policy bundles · 3

upsert_policy_bundle
validate_policy_bundle
diff_policy_bundles

Approvals · 2

create_approval_request
resolve_approval_request

Routing · 3

recommend_gateway_route
compare_gateway_routes
generate_gateway_routebook

Workflow · 2

plan_gateway_workflow
simulate_gateway_workflow

Observability & evidence · 5

query_gateway_observability
get_gateway_dashboard_summary
forecast_gateway_capacity
generate_governance_report
export_gateway_evidence_pack

Worked example

Onboarding a third-party server you did not write

The sequence that earns its keep: find out what the thing can do, price its risk, write a policy, prove the policy before it is live. Tool names are exact; argument names are illustrative — read the real schema from tools/list.

register_gateway_asset → discover_asset_tools Put the server behind the Gateway, then enumerate it. You now have an inventory of what a vendor’s server actually exposes, which is more than their README told you.
score_tool_risk Rank that inventory before anything calls it. A tool description written by someone else is an input to be assessed, not a fact — this is the step that catches a “read-only” tool that writes.
upsert_policy_bundle → validate_policy_bundle Write the rules for the risky ones and check the bundle parses and coheres before it governs traffic. An invalid bundle that fails closed denies everything, which is safe and extremely disruptive.
simulate_gateway_workflow Replay real traffic shapes and read what would have happened. Do this before the policy is enforced, not after someone files a ticket.
evaluate_tool_call In production, this is the call in the hot path. It returns one of the six enforcement outcomes above — branch on all six.
export_gateway_evidence_pack When someone asks what your agents were allowed to do last quarter, this is the answer, and it takes one call rather than a fortnight.

Steps one to four are onboarding and you run them once per asset. Step five runs on every call. Step six runs when an auditor arrives.

Routing, simulation, evidence

The three parts you will actually operate

Routebooks Named routes, not scattered rules A routebook binds a class of call to a destination and the policy that governs it. Reviewable as a unit, which matters when someone asks why a call went where it went.

Workflow simulation Change the policy before it bites Replay real traffic shapes against a candidate policy and see what would have been denied, redacted or held. The alternative is learning it in production on a Friday.

SIEM evidence Into the tooling your SOC already watches Decisions emit as structured events for your existing SIEM, so agent activity lands in the same place as the rest of your security telemetry rather than a dashboard nobody opens.

Third-party servers are the reason this product exists: you did not write them, you cannot audit their internals, and you still have to let your agents use them. Background: Securing Third-Party MCP Servers and MCP Gateway vs MCP Server.

Questions developers ask first

What is the difference between an MCP gateway and an API gateway?

An API gateway routes and rate-limits requests based on the calling service. An MCP gateway decides whether the identity behind an agent may perform a specific operation, reading ten inputs including the acting human’s roles, department and the actual argument values. Routing is not authorisation.

How many tools does Barzel Central Gateway expose?

25, as of 2 September 2026. They cover asset registration and discovery, tool evaluation and risk scoring, policy bundles, approvals, routing, workflow simulation, and observability and evidence. The Gateway never performs the business action itself — the server behind it does.

What are the six enforcement outcomes?

Denial, redaction, human approval, quorum, budget control, and per-user OAuth/OIDC execution. Only denial is a flat no; redaction lets legitimate work proceed with fields masked, and quorum requires more than one approver so a single compromised account cannot authorise an irreversible action alone.

Does the Gateway know which human is acting?

Yes, and that is the point. User id, roles, department, team and credential mode are policy inputs, so two people behind the same agent calling the same tool with the same arguments can legitimately get different answers. Calls can execute under the acting human’s own token rather than a shared service account.

Can I test a policy change before it affects production?

Yes — simulate_gateway_workflow replays real traffic shapes against a candidate policy and reports what would have been denied, redacted or held. The alternative is discovering it in production on a Friday.

What is a routebook?

A named binding between a class of call, its destination and the policy governing it. Because it is a single reviewable unit, it answers “why did this call go there” without reconstructing scattered rules.