# How It Works

> For AI agents: the complete documentation index is available at https://reshapr.io/llms.txt and the full documentation bundle at https://reshapr.io/llms-full.txt.

> reShapr is a zero-code AI translation layer. Instead of building an MCP server from scratch, you can use reShapr to instantly translate your existing APIs (REST, gRPC, GraphQL) into AI-native endpoints.

# How It Works

reShapr is a zero-code AI translation layer. Instead of building an MCP server from scratch, you can use reShapr to instantly translate your existing APIs (REST, gRPC, GraphQL) into AI-native endpoints.

With reShapr, you can create secure MCP servers in seconds without coding by connecting the platform to your existing API artifacts.

As of today, reShapr supports ingesting:

- [OpenAPI 3.x specifications](https://spec.openapis.org/oas/latest.html)
- [GraphQL schemas](https://spec.graphql.org/)
- [gRPC](https://grpc.io/docs/what-is-grpc/introduction/) / [Protocol Buffer definitions](https://protobuf.dev/programming-guides/proto3/)

## From API artifact to MCP endpoint

An imported API artifact defines a versioned Service and its operations. A Configuration Plan then selects the operations and attached reShapr Artifacts to expose, identifies the backend, and applies endpoint policies. An Exposition assigns that Plan to a Gateway Group, whose running Gateways serve the resulting MCP endpoint.

```mermaid
flowchart LR
	Artifact[API Artifact] --> Service[Versioned Service]
	Service --> PlanA[Configuration Plan A]
	Service --> PlanB[Configuration Plan B]
	PlanA --> ExpositionA[Exposition]
	PlanB --> ExpositionB[Exposition]
	ExpositionA --> Group[Gateway Group]
	ExpositionB --> Group
	Group --> GatewayA[Gateway]
	Group --> GatewayB[Gateway]
	GatewayA --> Backend[Backend API]
	GatewayB --> Backend
```

One Service can therefore produce multiple MCP surfaces. For example, one Plan can expose a small read-only surface while another includes a business-oriented Custom Tool and an output filter.

**Context Control** applies at two complementary points:

- At configuration time, a Plan selects Service operations and attached Prompts, Resources, Custom Tools, and output filters.
- At call time, the selected filters and output encoding can reduce or reshape a Tool response before it returns to the MCP client.

Once reShapr discovers your services, you configure:

- Security mechanisms
- Exposition options (all operations, read-only operations, etc.)
- Existing backend endpoint targets

Then reShapr exposes your MCP server through the Gateways selected by its Exposition.

:::info Core Architecture
reShapr separates configuration management from MCP request execution so that control-plane and Gateway placement can follow operational and network requirements.

The platform has two major parts:

- **Control plane**: centralizes exposition configuration and policies.
- **Data plane**: gateways that expose MCP servers and route runtime traffic.
:::

This architecture supports multiple deployment models:

1. **Local development**: control plane and Gateway run in one temporary environment.
2. **Centralized**: control plane and Gateways run in one managed environment.
3. **Hybrid or split**: control plane and Gateways run in different trust domains.
4. **Self-hosted or on-premises**: the organization operates the complete platform and its dependencies.

These names describe runtime topology, not commercial availability or service-level guarantees. See **[Deployment Models and Trust Boundaries](../explanations/deployment-models-trust-boundaries.md)** for the traffic flows and operational responsibilities of each model.

See also:

- **[Why reShapr?](./why-reshapr.md)**
- **[Services and Artifacts](../explanations/services-and-artifacts.md)**
- **[Configuration Plan and Exposition](../explanations/configuration-and-exposition.md)**
- **[Security Capabilities and Limits](../explanations/security-model.md)**
- **[Deploy a Hybrid Gateway](../how-to-guides/deploy-hybrid-gateway.md)**