Ryde over Model Context Protocol
Structured Ryde tools for AI agents, over the same gateway as REST.
COMING SOON — the MCP server is not accepting connections yet.
AI client
|
v
RYDE MCP SERVER <- tool discovery, tool calls
|
v
RYDE AGENT GATEWAY <- identity, scope, entitlement, confirmation
|
v
RYDE DOMAIN SERVICES
rides · food · delivery · services · tasks
MCP is an interface, not a backend. Business rules live in the domain services and the gateway enforces authorization in one place, so a tool call and the equivalent REST call are subject to identical checks. There is no logic that exists only on the MCP side, and therefore no behaviour that can drift between them.
Authorization
- The MCP server is an OAuth protected resource. Clients discover the authorization server through protected-resource metadata and run the same authorization-code + PKCE flow.
- Tokens are audience-bound. A token minted for Ryde is only accepted by Ryde, and must never be forwarded to another service.
- 401 means authentication is missing or invalid. 403 means authenticated but not permitted — either a missing scope or a missing entitlement, distinguished by the error code.
- tools/list is filtered by the scopes the customer granted.
Transacting tools stay VISIBLE to a customer without Ryde One, carrying the requirement in their description. Hiding them would leave an agent unable to explain why it cannot help — the customer would just be told no. Showing them lets the agent price the thing, then explain exactly what a membership unlocks.
A worked agent flow
"Order me lunch from the place I like."
|
search_restaurants scope food.read no membership needed
|
get_restaurant_menu scope food.read no membership needed
|
quote_food_order scope food.read returns quote_id + total
|
>> agent shows the customer the basket and the price <<
|
>> customer confirms <<
|
place_food_order scope food.order Ryde One required
| quote_id + Idempotency-Key
v
get_food_order tracking, never membership-gated