For the complete documentation index, see llms.txt.
Skip to main content

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:

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. Running proxies register logical Gateways in that group and serve the resulting MCP endpoint.

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 proxies whose registered Gateways are selected by its Exposition.

Core Architecture

reShapr separates configuration management from MCP request execution so that control-plane and proxy placement can follow operational and network requirements.

The platform has two major parts:

  • Control plane: centralizes exposition configuration and policies.
  • Data plane: proxies that expose MCP servers and route runtime traffic.

This architecture supports multiple deployment models:

  1. Local development: control plane and proxy run in one temporary environment.
  2. Centralized: control plane and proxies run in one managed environment.
  3. Hybrid or split: control plane and proxies 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 for the traffic flows and operational responsibilities of each model.

See also:

Agent View