---
title: "MCP Integration — One Server, Every Framework | roji.ai"
description: "Connect any MCP-capable agent to the ROJI catalog: OAuth 2.1 agent identity, async-by-construction tools, typed results, fee previews before any charge, and the full order lifecycle at mcp.roji.ai."
doc_version: 7025a5b9e485
last_updated: 2026-09-10
---
# MCP Integration — One Server, Every Framework | roji.ai

Developers

MCP

One MCP server. Every agent runtime.

mcp.roji.ai makes the service catalog reachable from Claude Code, Claude, Cursor, the OpenAI Agents SDK, LangGraph, and everything else that speaks MCP — in an afternoon, with a CLI for whatever doesn't.

Get started

## Identity: every agent answers to someone

Agents authenticate with OAuth 2.1 — client credentials, or token exchange from your agent platform. Every agent token is bound to a **Principal**: the accountable person or organization that sets its budgets and answers its escalations. Anonymous agents can't order, can't pay, and can't build a record. That's a feature: it's what makes the buying side of this platform trustable enough for a business to sell into.

Scopes are narrow and boring:

```text
orders:write     place, cancel, and answer on orders; fulfill info requests
orders:read      read orders, deliverables, events
catalog:read     search and read service listings and fee previews
orders:review    checkpoint approvals, refund requests, reviews
billing:read     payment methods, spend-policy headroom, receipts
```

Spend limits are enforced platform-side. There is no scope that lets an agent raise its own ceiling.

## Async by construction

Real-world services take hours to weeks. No ROJI tool blocks on a human — ordering tools return immediately with an order id and current state, and your agent observes progress through webhooks, polling, or MCP resource reads:

```text
roji://orders/{orderId}          current state, open blockers, SLA clock remaining
roji://orders/{orderId}/events   full event history (same payloads as webhooks)
roji://services/{serviceId}      the listing: input schema, deliverable schema, SLA, price
```

Load the order into context instead of reconstructing it from tool-call history. The full lifecycle contract is on the [order lifecycle page](/developers/ordering).

## The tool surface

Grouped by what your agent is doing:

```text
discover     search_services · get_service
buy          order_service · get_order · list_orders · cancel_order
communicate  answer_question · fulfill_info_request · approve_checkpoint
receive      get_deliverable
resolve      request_refund
reputation   review_business
```

`get_service` carries the **fee preview** — itemized list price, platform fee, and processing — so the number your agent shows a human before ordering is the number that gets charged. Tools with stable result shapes declare output schemas, so `search_services`, `get_service`, `get_order`, and `get_deliverable` return typed results your code consumes without prompt-parsing.

The business side — catalog CRUD, the order queue, refund handling — runs in a human console first and lands on MCP after.

## Protocol posture

The server is built on the MCP `2026-07-28` stack — stateless core, version negotiation, extensions — and serves `2025-11-25` clients on the same endpoint. Clients that negotiate the **Tasks** extension get protocol-native poll/resume on long-running calls and mid-call input for typed Questions; everyone else gets the same lifecycle over webhooks and polling. No capability is MCP-only: every tool has a documented HTTP endpoint and a CLI command underneath.

Integrate

Get started

## Sitemap

- [Every public page, as markdown](/sitemap.md)
- [llms.txt](/llms.txt) · [AGENTS.md](/AGENTS.md) · [auth.md](/auth.md)