Want to offer AI governance under your own brand? Explore partnership models →

For Developers

Developing with the Brutor AI Gateway.

One OpenAI-compatible endpoint. Any LLM provider, MCP tools, A2A agents, skills and your own portal — all governed, all observable, no SDK lock-in.

POST 
# OpenAI-compatible chat completions — point your client at /v1/proxy/llm
$ curl -X POST https://gateway.brutor.ai/v1/proxy/llm/chat/completions 
    -H "Authorization: Bearer sk_brutor_..." 
    -H "Content-Type: application/json" 
    -d '{"model":"gpt-4o","messages":[{"role":"user","content":"Hello"}]}'

# Same gateway, MCP tools — no client changes
$ curl -X POST https://gateway.brutor.ai/v1/proxy/mcp/{server_id} 
    -H "Authorization: Bearer sk_brutor_..." 
    -d '{"jsonrpc":"2.0","method":"tools/call","params":{...}}'
/built on open standards/

Drop in the gateway URL. Your code stays the same.

We didn’t invent a new protocol. The Brutor AI Gateway speaks OpenAI’s API for LLMs, MCP’s JSON-RPC 2.0 for tools, and A2A for agents. OAuth flows are brokered at the gateway, OpenTelemetry traces flow out on every call. There’s no Brutor SDK to install, no proprietary client to maintain, no lock-in to migrate away from.

That’s why pointing any OpenAI SDK, any MCP-aware client, or any A2A-spec agent at the gateway is usually a one-line config change.

OpenAI API MCP A2A OAuth 2.0 JSON-RPC 2.0 OpenTelemetry
/ENTRYPOINTS/

Six ways to build on the gateway.

From a one-line LLM swap to a full A2A agent network. Pick the entry point that matches your stack today — the same governance, observability and audit apply to all of them.

01

Unified LLM API

One OpenAI-compatible endpoint fronts OpenAI, Anthropic, Bedrock, Gemini, Azure, Mistral and self-hosted models. Switch providers without touching client code.

client = OpenAI(
  base_url="https://gateway.brutor.ai/v1/proxy/llm",
  api_key="sk_brutor_...",
)
client.chat.completions.create(
  model="claude-sonnet-4-6",
  messages=[...]
)
02

MCP proxy endpoint

Connect your agents to any MCP server through one URL. The gateway brokers OAuth, enforces per-tenant tool allow-lists, records arguments, and audits every call.

# proxy any MCP server in the registry
POST /v1/proxy/mcp/{server_id}
Authorization: Bearer sk_brutor_...

# JSON-RPC 2.0 — tools/list, tools/call, ...
03

Call an agent skill

Skills are versioned, composable workflows — model + MCP tools + scripts + templates. Publish once, run from any AI client. Skills are exposed via MCP tools/call through the same MCP proxy endpoint.

POST /v1/proxy/mcp/system-agent-skill-server

{ "jsonrpc": "2.0", "id": 1,
  "method": "tools/call",
  "params": {
    "name": "skill__triage-ticket",
    "arguments": { "ticket_id": "7421" }
  } }
04

Build your own portal

Use the same Portal API the Brutor User Portal does. Sign-in, accessible models, MCP servers, knowledge bases, agent skills. Bring your own UI, keep all governance.

POST /v1/portal/auth/login
GET  /v1/portal/models/
GET  /v1/portal/servers/
GET  /v1/portal/knowledgebases/
GET  /v1/proxy/skills/catalog
05
Experimental

Develop your own agent (A2A)

Publish your agent as A2A. The gateway serves the agent card at the spec well-known URL, brokers message turns and tasks, and applies the same guardrails — to MCP-native and non-MCP agents alike.

GET  /.well-known/agent-card/{tenant_id}/{card_name}.json
POST /a2a/{tenant_id}/{card_name}/message:send
POST /a2a/{tenant_id}/{card_name}/message:stream
06

Knowledge base & search

Upload to a per-team knowledge base, retrieve with hybrid search, ground answers in your own documents. Embeddings stay inside your infrastructure.

POST /v1/admin/knowledge-base/collections/{id}/documents
POST /v1/admin/knowledge-base/collections/{id}/search

{ "query": "Q3 EMEA renewal terms",
  "top_k": 8 }
/drop-in clients/

Already using Claude Code, Goose, LangChain or Open WebUI?

Point them at the gateway. Every governance, audit and quota feature applies — no SDK changes, no client patches.

Open WebUI

Run Open WebUI with the gateway as its OpenAI-compatible model source. Users log in to Open WebUI; the gateway sees the API key behind it.

docker run -d -p 3000:8080 
  -e OPENAI_API_BASE_URL="https://gateway.brutor.ai/v1/proxy/llm" 
  -e OPENAI_API_KEY="sk_brutor_..." 
  ghcr.io/open-webui/open-webui:main

Goose

Configure Goose’s built-in OpenAI provider with your gateway URL and API key. MCP servers configured at the Brutor side flow in automatically.

# ~/.config/goose/config.yaml
provider: openai
host: "https://gateway.brutor.ai/v1/proxy/llm"
api_key: "sk_brutor_..."
model: "gpt-4o"

LangChain & LangGraph

Use the standard ChatOpenAI client with a base URL override. Every LLM call, tool call and chain step lands in your audit log.

llm = ChatOpenAI(
  base_url="https://gateway.brutor.ai/v1/proxy/llm",
  api_key="sk_brutor_...",
  model="claude-sonnet-4-6",
)

Claude Code

Point Claude Code at the gateway. Per-developer keys, request & tool-call audit, with the rest of your client toolchain unchanged.

# ~/.claude/settings or env
export ANTHROPIC_BASE_URL="https://gateway.brutor.ai"
export ANTHROPIC_AUTH_TOKEN="sk_brutor_..."
/MCP server development/

Developing your own MCP servers?

MCP Workbench

Test, debug and inspect any MCP server.

Walk through OAuth flows, list and call tools, view raw JSON-RPC requests and responses side by side — all without writing a client.

Open the Workbench
MCP Developer Bootcamp

Hands-on Udemy course.

Build MCP servers from scratch — protocol fundamentals, OAuth, tool design, and connecting your servers to the Brutor AI Gateway.

Take the course
/start the conversation/

Build on the Brutor AI Gateway — free, today.

Start Free Trial

Includes the gateway, a sandboxed playground, and all 20+ developer guides — quickstart, architecture, MCP development, A2A, OAuth, drop-in client recipes, and the MCP Workbench.

Scroll to Top