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

For Developers

Build it governed from the first commit.

Whatever you’re developing — an AI application, an MCP server, an agent, an Agent Skill — run it through the Brutor AI Platform and it ships with routing, guardrails, approvals, quotas and a full audit trail. Open standards, no SDK lock-in.

Documentation is live at docs.brutor.ai

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 skills, 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 — and from that line on, every call is governed.

OpenAI API MCP A2A OAuth 2.0 JSON-RPC 2.0 OpenTelemetry
/what are you building/

Pick your lane. Governance comes with it.

Six kinds of builders use the platform. Whichever you are, the same control plane sits under your work — guardrails, budgets, approvals, audit — and every lane has a hands-on guide at docs.brutor.ai.

01

“I’m building an AI application”

You want LLM routing and guardrails without wiring them yourself. One OpenAI-compatible endpoint fronts OpenAI, Anthropic, Bedrock, Gemini, Azure, Mistral and self-hosted models — with PII redaction, prompt-injection checks, budgets and failover applied to every call.

Guide: Call LLMs through the gateway 
client = OpenAI(
  base_url="https://gateway.brutor.ai/v1/proxy/llm",
  api_key="sk_brutor_...",
)
client.chat.completions.create(
  model="claude-sonnet-4-6",  # routed + guardrailed
  messages=[...]
)
02

“I’m building an MCP server”

Register your server once and every agent in the org reaches it through the gateway — which brokers OAuth, enforces per-group tool allow-lists and argument policies, applies guardrails to inputs and outputs, and audits every tools/call.

Guide: Register your MCP server 
# your server, registered once:
https://tools.acme.dev/mcp → server_id: acme-tools

# every caller now goes through governance
POST /v1/proxy/mcp/acme-tools
Authorization: Bearer sk_brutor_...
03

“I’m building an agent”

Route your agent’s LLM and tool calls through the gateway, then publish it to other teams as an A2A agent — signed card at the spec well-known URL, message turns brokered, guardrails on inbound and outbound traffic alike.

Guides: Build an agent & A2A 
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
04
New

“I’m authoring Agent Skills”

Package versioned agent workflows — instructions, scripts, resources, templates. Agents discover and load them by progressive disclosure over MCP; every step is guardrailed, quota’d, approval-gated and audited, and skill code only ever runs in Brutor’s sandbox.

Guide: Agent Skills 
POST /v1/proxy/mcp/system-agent-skill-server-{tenant}

# discover → load → act, each step governed
{ "method": "tools/call",
  "params": {
    "name": "skills__load",
    "arguments": { "skill_name": "revenue-report" }
  } }
# then: skills__run_script · skills__read_resource · skills__render_template
05

“I’m building a chat client or portal”

Use the same Portal API the Brutor User Portal runs on: sign-in, accessible models, MCP servers, knowledge bases, approvals and notifications. Bring your own UI — every request your users make stays inside governance.

Guide: Build a custom portal 
POST /v1/portal/auth/login
GET  /v1/portal/models/
GET  /v1/portal/servers/
GET  /v1/portal/knowledgebases/
GET  /v1/portal/approvals
06

“I’m grounding AI in our own data”

Upload to a per-team knowledge base, retrieve with hybrid search, ground answers in your own documents. Embeddings stay inside your infrastructure, and access follows the same resource-group model as everything else.

Reference: Portal & KB API 
POST /v1/admin/knowledge-base/collections/{id}/documents
POST /v1/admin/knowledge-base/collections/{id}/search

{ "query": "Q3 EMEA renewal terms",
  "top_k": 8 }
/documentation/

New: full documentation at docs.brutor.ai.

Hands-on guides for every builder above, full API references for every surface, and a quickstart that gets the whole platform running in about ten minutes.

Getting started

Quickstart & governance tour.

Run the full stack with Docker Compose, send your first governed LLM call, then trip a budget, a rate limit and a PII guardrail on purpose.

Start in 10 minutes
Build with Brutor

Guides for every persona.

LLM API, agents, MCP clients and servers, coding agents, custom portals, A2A, Agent Skills, OAuth, setup scripts — each one hands-on with runnable requests.

Browse the developer guides
Reference

Every endpoint, documented.

LLM proxy, Portal API, Admin API, MCP / A2A / OAuth / Skills, environment variables, ports and services — request and response bodies included.

Open the API reference
/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.

Download Free Trial

Includes the gateway, a sandboxed playground, and the MCP Workbench. Full guides and references for everything on this page live at docs.brutor.ai.

Scroll to Top