Developer documentation · Updated 2 September 2026
Connect a Barzel server, and know what it will refuse.
Five MCP servers, one transport, one connection pattern. This page covers what is true of all of them — how you connect, how you authenticate, how you enumerate what a server can do, and what a governed refusal looks like on the wire. Each product then has its own reference page for the parts that differ.
01 · Quickstart
Three steps, and the third one is the honest one
Barzel servers are distributed through the MCPize marketplace. Your endpoint URL and key are issued on the listing when you subscribe — we do not mint credentials on this website, and we do not publish an endpoint we would then have to rotate.
- Step 01 Subscribe on the listing and copy the endpoint Every product page links its listing. Four of the five have a free tier, so you can get an endpoint without a card. Scripture Intelligence needs no account at all.
- Step 02 Point your MCP client at it No SDK of ours to install. Barzel speaks the protocol your client already speaks, over ordinary HTTPS.
- Step 03 Ask the server what it can do, rather than trusting this page A tools/list call returns the running server’s own tool names and JSON Schema for every argument. That enumeration is authoritative and cannot drift out of date the way a documentation table can. Where this site states a count, the count came from the same call.
{
"mcpServers": {
"barzelvault": {
"type": "http",
"url": "<endpoint issued with your listing>",
"headers": {
"Authorization": "Bearer <your key>"
}
}
}
}
Key names vary slightly between clients — some use transport rather than type, some read the bearer token from an environment variable. The two values that matter are the endpoint and the key.
02 · Transport and protocol
Streamable HTTP, JSON-RPC 2.0, nothing bespoke
All five servers speak the Model Context Protocol over Streamable HTTP with JSON-RPC 2.0 framing. There is no Barzel wire format, no proprietary SDK and no long-lived socket to babysit. If your client already talks to an MCP server, it already talks to ours.
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": {},
"clientInfo": {
"name": "your-client",
"version": "1.0.0"
}
}
}
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/list"
}
// Also available on every server:
// resources/list
// resources/templates/list
// prompts/list
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "<name from tools/list>",
"arguments": {
"...": "..."
}
}
}
Your client sends the protocol revision it supports and the server negotiates from there; you do not need to match the value shown above. Requests are ordinary HTTPS POSTs, so a stalled call is a stalled request — retry it, and read errors and refusals before you retry a governed one.
03 · Authentication
Two layers: getting in, and being allowed to act
Reaching a Barzel server and being permitted to do something through it are separate decisions, and they fail differently. The bearer token on the connection identifies your tenant. What that connection may then do is decided per call, against the credentials you supplied for the downstream system and the policy that matched. Which is why a valid token still gets refusals — by design.
| Server | Connection auth | Downstream credential model |
|---|---|---|
| BarzelVault | Bearer key from the listing | Dynamic operation-specific OAuth scopes. A call outside the scope that matched is answered with an insufficient_scope challenge naming the scope required, rather than a generic 403. |
| Central Gateway | Bearer key from the listing | Per-user OAuth / OIDC. The acting human’s identity, roles, department and team are policy inputs, so two people behind the same agent can get different answers. |
| FinOps Atlas | Bearer key from the listing | Read credentials you supply for each connected finance or document system. Evidence assembly is read-oriented; write paths are gated separately. |
| BarzelOps | Bearer key from the listing | Customer-owned OAuth tokens, supplied per tenant and never pooled across tenants. You grant them, you revoke them, and revocation takes effect on the next call. |
| Scripture Intelligence | None — public endpoint | Not applicable. The corpus is public-domain text and the server holds no credentials of yours, which is why it is the right target for your first connection test. |
In no case is a credential placed in a prompt, a tool description, a resource body or an audit record. The security page states that as an architectural rule and explains what it costs us to keep it. Background on the patterns themselves: MCP Authentication Patterns.
04 · Capability surface
What each server exposes, as of this page’s date
Counts below match the marketplace listings and the servers’ own enumeration calls on the date at the top of this page. They are a planning aid, not the contract — the contract is whatever tools/list returns to you. Every product reference page lists its tool names in full.
| Server | Tools | Resources | Templates | Prompts |
|---|---|---|---|---|
| BarzelVault | 30 | 25 | 17 | 21 |
| FinOps Atlas | 30 | 20 | — | 15 |
| Scripture Intelligence | 54 | 36 | — | 75 |
| Central Gateway | 25 | — | — | — |
| BarzelOps | 40* | — | — | — |
* BarzelOps gates its surface by plan: the Free tier exposes 10 tools, Pro 26, and Team or Enterprise the complete 40. A tool you are not entitled to is absent from tools/list rather than present and failing — deliberately, so a model cannot spend a turn attempting it.
Resource, template and prompt counts are shown only where a server publishes them. An em dash means we are not going to guess on your behalf — call resources/list and prompts/list and read the answer.
05 · Errors and refusals
A refusal is a result, not a failure
This is the part most clients get wrong. A transport error means your call did not happen and retrying may help. A governed refusal means your call was evaluated and the answer was no — retrying identically will produce the same no, and an audit event has already been written. Treat them as different branches.
A worked example of the decision path, with the inputs that produce each outcome, is on the BarzelVault reference.
06 · Call limits
What each plan buys you, per month
Plans are billed and enforced on the marketplace listing, not here. Prices and quotas below match the listings on this page’s date; the listing is authoritative if they ever diverge.
| Server | Free tier | Paid plans |
|---|---|---|
| BarzelVault | None | Dev Free · 10,000 calls | Team $199/mo · 75,000 | Business $799/mo · 750,000 | Enterprise $3,999/mo · 5,000,000 |
| Central Gateway | 1,000 / mo | Starter $10/mo · 10,000 | Team $79/mo · 100,000 | Business $149/mo · 250,000 |
| FinOps Atlas | 500 / mo | Starter $29/mo · 1,000 | Growth $99/mo · 5,000 | Business $249/mo · 15,000 | Enterprise $799/mo · 50,000 |
| BarzelOps | 100 / day | Pro $19/mo · 15,000 | Team $49/mo · 50,000 | Enterprise $199/mo · unlimited |
| Scripture Intelligence | Free, unmetered | No paid tier. No signup, no key. |
07 · Per-product reference
One page per server
What is not here yet
Three gaps we would rather name than paper over
- Argument-level schemas Tool names are listed in full on each product reference page. The JSON Schema for each tool’s arguments is not mirrored here: the servers publish it through tools/list, and a hand-copied table would eventually contradict the running server. Read it from the call, and treat any argument name in our worked examples as illustrative.
- No sandbox on this domain There is no in-browser console here to try a call. The nearest thing is Scripture Intelligence, which is genuinely public: point a client at it and you have exercised the transport, the handshake and the enumeration path in under a minute.
- No client libraries We publish no SDK, in any language. That is deliberate rather than pending — MCP is the interface, and a wrapper of ours would only be a version of it that ages.
Common questions
Questions developers ask first
What transport do Barzel MCP servers use?
Streamable HTTP with JSON-RPC 2.0 message framing, as specified by the Model Context Protocol. Any compliant MCP client can connect without a bespoke adapter, and there is no Barzel SDK to install.
How do I see the tools a Barzel server exposes?
Call tools/list after initialize. Each server returns its own tool names and the JSON Schema for every argument, so the enumeration cannot drift out of date the way a documentation table can. Where this site states a count, the count came from the same call.
Is there a Barzel MCP server I can call without signing up?
Yes. Barzel Scripture Intelligence is published free at scripture-intelligence-server.mcpize.run with no signup and no key, which makes it the fastest way to confirm your client speaks to a Barzel server correctly.
What happens when a policy refuses an action?
The call returns a structured refusal rather than a transport failure. The response names the outcome applied — deny, dry-run or require approval — and an audit event is written before the response reaches you. Do not retry it as though it were a network error.
Do I need a different client for each Barzel server?
No. All five speak the same protocol over the same transport, so one client configuration pattern covers them. Only the endpoint and the credential change.
Where do I get an endpoint and a key?
On each product’s MCPize marketplace listing, linked from every product page. We do not mint credentials on this website. Four of the five have a free tier, and Scripture Intelligence needs no account at all.