Wrap-to-MCP Reference

Introduction

Wrap-to-MCP is a production console that converts any REST API into a Model Context Protocol (MCP) server. You don't write code or set up infrastructure. Import your OpenAPI 3.x or Swagger 2.0 spec once in JSON or YAML, refine the generated tools, and connect MCP-compatible clients like Claude, Cursor, or VS Code directly to your API.

Things are organized into workspaces. Each workspace holds one or more servers, and each server wraps one upstream REST API, turning its endpoints into tools you can manage individually. There's also a workspace-level MCP endpoint that combines all active servers behind a single URL.

Quick Start

Four steps to a working MCP endpoint. Should take about five minutes.

# All servers in the workspace
https://wrapmcp.my.id/mcp/{workspace}

# One specific server
https://wrapmcp.my.id/mcp/{workspace}/{prefix}

# One specific tool (also accepts raw JSON)
https://wrapmcp.my.id/mcp/{workspace}/{prefix}/{tool_name}

Core Concepts

Workspaces

A workspace is the top-level container. It has a unique slug that forms part of every MCP URL in that workspace. Workspaces can be shared across multiple users via the members system.

• One owner (the creator) plus optional invited members
• An aggregate MCP endpoint at /mcp/{workspace} covers all active servers
• Workspace-level API keys apply to all servers and tools inside it
• Can be deactivated to take all servers offline without deleting them

MCP Servers

An MCP server wraps one upstream REST API. It has a prefix (the slug used in the endpoint URL) and a target URL (the base URL all requests are proxied to).

• Prefix must be unique within the workspace (for example payments)
• Target URL can be changed at any time without affecting the MCP endpoint URL
• Servers can be individually activated or deactivated
• Server-level API keys override workspace-level keys for that server
• Server configs are cached in memory to reduce database lookups

Tools

A tool corresponds to one REST API operation. It has a name (the MCP tool name), an HTTP method, a path template, a human-readable description, and a JSON Schema for its input parameters.

• Tools can be enabled or disabled individually without restarting the server
• Path parameters use {param} syntax
• Query params and request body fields are automatically classified from the JSON Schema
• Tool descriptions are what AI models rely on when choosing which tool to call
• Per-tool API keys can be issued for fine-grained client access control

API Keys

API keys authenticate requests to MCP endpoints. They follow a three-tier hierarchy:

Create keys at the workspace, server, or tool level depending on how broadly you want a client to authenticate.

Importing APIs

OpenAPI / Swagger

Wrap-to-MCP supports OpenAPI 3.x and Swagger 2.0 specs in JSON or YAML format. You can:

• Paste a publicly accessible raw JSON or YAML spec URL, or a Swagger UI page URL
• Upload a local .json, .yaml, or .yml file

The parser automatically:

• Derives a tool name from operationId, or falls back to {method}_{path}
• Extracts path parameters, query parameters, and request body fields into a unified JSON Schema
• Identifies $ref schemas and surfaces them for description enrichment
• Copies any existing summary or description from the spec

Manual endpoints

If you do not have an OpenAPI or Swagger spec, you can define endpoints manually from the server detail page.

• A unique tool name such as get_order_by_id
• HTTP method such as GET, POST, or PATCH
• Path template such as /orders/{id}
• Description that explains what the tool does and when to use it
• JSON Schema object for the inputSchema

Writing tool descriptions

Good descriptions have the biggest impact on whether AI models pick the right tool.

• Start with a verb
• Describe when to call the tool, not just what it does
• Mention important parameters if they change the result
• Keep it short enough that models can scan the tool list easily
• Avoid implementation details that do not help the caller

MCP Endpoint Reference

URL structure

There are three endpoint shapes, all using MCP Streamable HTTP transport. The single-tool endpoint also accepts a plain JSON body if you do not need the full JSON-RPC envelope.

JSON-RPC methods

All endpoints speak JSON-RPC 2.0.

// Request
{
 "jsonrpc": "2.0",
 "id": 1,
 "method": "initialize",
 "params": { ... }
}

// Response
{
 "jsonrpc": "2.0",
 "id": 1,
 "result": {
 "protocolVersion": "2024-11-05",
 "capabilities": { "tools": {} },
 "serverInfo": { "name": "wrap-to-mcp", "version": "..." }
 }
}

{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }

{
 "jsonrpc": "2.0",
 "id": 3,
 "method": "tools/call",
 "params": {
 "name": "get_order",
 "arguments": { "id": "ord_123" }
 }
}

Authentication

MCP endpoints accept API keys through either of these headers:

X-API-Key: wtm_your_key_here
# or
Authorization: Bearer wtm_your_key_here

The effective key is resolved by scope hierarchy: tool-level first, then server-level, then workspace-level. If no key is configured at any scope, the endpoint is public.

Connecting Clients

Most MCP clients need the same three values: the endpoint URL, the HTTP transport type, and an API key header. Start with a server-level endpoint while you test, then switch to the workspace endpoint if you want one client to access multiple APIs.

Claude Desktop

Add a server entry to Claude Desktop's configuration file. On macOS, this is typically ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows, open Claude Desktop's config editor and add the same JSON entry.

{
 "mcpServers": {
 "wrap-to-mcp": {
 "command": "npx",
 "args": [
 "-y",
 "@modelcontextprotocol/http-client",
 "https://wrapmcp.my.id/mcp/my-workspace/my-server"
 ],
 "env": {
 "MCP_API_KEY": "wtm_your_key_here"
 }
 }
 }
}

Visual Studio Code

Create or update .vscode/mcp.json in your workspace and register Wrap-to-MCP as an HTTP MCP server.

{
 "servers": {
 "wrap-to-mcp": {
 "type": "http",
 "url": "https://wrapmcp.my.id/mcp/my-workspace/my-server",
 "headers": {
 "X-API-Key": "wtm_your_key_here"
 }
 }
 }
}

Cursor

In Cursor, open Settings → Features → MCP and add a new server with the http transport type.

{
 "mcpServers": {
 "wrap-to-mcp": {
 "transport": "http",
 "url": "https://wrapmcp.my.id/mcp/my-workspace/my-server",
 "headers": {
 "X-API-Key": "wtm_your_key_here"
 }
 }
 }
}

Claude Code CLI

Add the remote MCP server from your terminal, then restart Claude Code so it picks up the new entry.

claude mcp add --transport http wrap-to-mcp  https://wrapmcp.my.id/mcp/my-workspace/my-server  --header "X-API-Key: wtm_your_key_here"

OpenCode CLI

OpenCode can add remote MCP servers interactively. Start the add flow, choose a remote HTTP server, then paste the Wrap-to-MCP endpoint and API key header when prompted.

opencode mcp add

OpenClaw

OpenClaw setups vary by gateway and plugin. If your deployment uses an MCP bridge or remote MCP connector, point that connector at your Wrap-to-MCP endpoint and send the API key in anX-API-Key header.

{
 "type": "http",
 "url": "https://wrapmcp.my.id/mcp/my-workspace/my-server",
 "headers": {
 "X-API-Key": "wtm_your_key_here"
 }
}

n8n

In n8n, add a remote MCP server to your AI workflow or agent configuration, then use the Wrap-to-MCP server URL with an API key header.

{
 "name": "wrap-to-mcp",
 "transport": "http",
 "url": "https://wrapmcp.my.id/mcp/my-workspace/my-server",
 "headers": {
 "X-API-Key": "wtm_your_key_here"
 }
}

Custom / SDK

Any HTTP client that can send JSON-RPC 2.0 POST requests works.

import { Client } from "@modelcontextprotocol/sdk/client/index.js"
import { StreamableHttpClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js"

const transport = new StreamableHttpClientTransport(
 new URL("https://wrapmcp.my.id/mcp/my-workspace/my-server"),
 {
 requestInit: {
 headers: { "X-API-Key": "wtm_your_key_here" },
 },
 },
)

const client = new Client({ name: "my-client", version: "1.0.0" })
await client.connect(transport)

const { tools } = await client.listTools()
console.log(tools)

const result = await client.callTool({
 name: "get_order",
 arguments: { id: "ord_123" },
})
console.log(result.content)

Managing Tools

Enable / disable tools

Each tool on the server detail page has a toggle switch. Disabled tools won't appear intools/list responses and can't be called.

Edit definitions

Click a tool name to open the edit drawer. You can modify:

• Description
• HTTP method
• Path template
• Input schema for accepted parameters

Test harness

The Test button opens an in-browser execution panel. Fill in the tool arguments as JSON and run the call.

• HTTP status code returned by the upstream API
• Full response body
• Schema validation errors if arguments are invalid
• Whether the call was treated as a success or error

Auth & Security

Wrap-to-MCP keeps workspace access and endpoint access separate. Sign-in controls who can manage a workspace in the console, and API keys control which clients can call MCP tools.

Workspace access

Every workspace has an owner and can include additional members. Owners create invite links, manage membership, and control the servers, tools, and API keys inside the workspace.

• Owners can invite or remove members from the workspace.
• Members can access the workspace they were invited to.
• Workspace membership does not expose other workspaces automatically.

API key scopes

API keys are generated from the API Keys tab on the workspace, server, or tool detail page. Pick the narrowest scope that matches the client you are connecting.

Scope resolution at request time (highest wins):

• Tool-level key
• Server-level key
• Workspace-level key
• No key configured means the endpoint is public

Teams & Members

Workspaces can have multiple members. The owner manages access from the Members tab using a token-based invite system.

Invite links

Invites are created by entering the invitee's email address. The system generates a unique token and a shareable link.

https://wrapmcp.my.id/invite/{token}

• Each invite link is valid for 7 days from creation
• Only one pending invite per email address per workspace is allowed
• The invite page is publicly viewable and shows the workspace name, invitee email, and expiration
• To accept, the invitee must log in with the matching email and click Accept
• Pending invites can be revoked at any time from the Members tab

Managing members

Once a user accepts an invite, they appear in the members list. The workspace owner can:

• Search members by email address
• Filter by active or inactive status
• Temporarily deactivate a member without removing them
• Remove members when they no longer need access