This server lets LLMs interact with any REST API via MCP, executing HTTP requests and analyzing responses.
Execute HTTP requests: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS
Return full responses with smart truncation of large JSON payloads
Generate TypeScript interfaces from live API responses
Describe response structure (keys, types, array lengths) without full body
Extract specific fields using dot-notation paths (e.g. data.items[].name)
Set a bearer token at runtime for the current session
Configure base URL, auth token, custom headers, and response size limits via environment variables
Resolve auth tokens from project .env.mcp, MCP config env vars, or session token
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rest-api-mcp fetch all users from the /users endpoint"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A lightweight Model Context Protocol (MCP) server that lets LLMs interact with any REST API. It executes HTTP requests and provides optimized response analysis, including automatic TypeScript interface generation from live API responses.
Full HTTP support — GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS
Smart response truncation — large JSON payloads are intelligently reduced (arrays sliced, structure preserved) instead of being cut mid-string
TypeScript type generation — automatically derives TypeScript interfaces from API response structures
Response structure analysis — inspect keys, types, and array lengths without returning the full body
Field extraction — pull specific fields using dot-notation paths (e.g. data.items[].name)
Flexible authentication — bearer token resolution chain: project .env.mcp file → MCP config env var → session token
Custom headers — inject global headers via HEADER_* environment variables
Zero external runtime dependencies — uses only the MCP SDK and Node.js built-in fetch
Related MCP server: anyapi-mcp-server
Tool | Description |
| Execute a request and return the full (smart-truncated) response |
| Execute a request and return the response structure + generated TypeScript interfaces (no full body) |
| Execute a request and return only the generated TypeScript interfaces |
| Execute a request and extract specific fields by dot-notation paths |
| Set a bearer token for the current session |
Node.js >= 18.0.0
pnpm (or npm/yarn)
git clone <repository-url>
cd rest-api-mcp
pnpm install
pnpm buildAdd the server to your MCP client configuration (e.g. Claude Desktop claude_desktop_config.json):
{
"mcpServers": {
"rest-api": {
"command": "node",
"args": ["/path/to/rest-api-mcp/dist/index.js"],
"env": {
"REST_BASE_URL": "https://api.example.com",
"REST_BEARER_TOKEN": "your-token-here"
}
}
}
}All configuration is done via environment variables:
Variable | Required | Description |
| No* | Fallback base URL for all API requests (e.g. |
| No | Bearer token for authentication |
| No | Max response size in bytes before smart truncation (default: |
| No | Additional directory to search for |
| No | Custom headers injected into every request (e.g. |
The base URL is resolved in this order (first match wins), fresh on every request:
Project .env.mcp file — REST_BASE_URL in a .env.mcp file in the working directory or REST_ENV_DIR. Lets each project point at its own API with a single global server registration.
MCP config env var — REST_BASE_URL set in the MCP server configuration.
Example project .env.mcp:
REST_BASE_URL=https://api.example.com/api
REST_BEARER_TOKEN=your-token-hereIf neither is set, request tools fail with a clear error instead of hitting a placeholder host.
Bearer tokens are resolved in this order (first match wins):
Project .env.mcp file — REST_BEARER_TOKEN in a .env.mcp file in the working directory or REST_ENV_DIR. Re-read on every request, so token rotation is supported without restarting the server.
MCP config env var — REST_BEARER_TOKEN set in the MCP server configuration.
Session token — set at runtime via the rest_set_token tool.
If a 401 or 403 response is received and no token is configured, the server returns an auth hint suggesting resolution steps.
rest_request({ method: "GET", endpoint: "/users" })rest_request({ method: "GET", endpoint: "/users", query: { page: "1", limit: "10" } })rest_types({ method: "GET", endpoint: "/users/1", typeName: "User" })rest_describe({ method: "GET", endpoint: "/products", typeName: "ProductList" })rest_extract({ method: "GET", endpoint: "/orders", fields: ["data[].id", "data[].status", "meta.total"] })# Watch mode with hot reload
pnpm dev
# Build for production
pnpm build
# Run the built server
pnpm startMIT
Execute an HTTP request and return the response structure (keys, types, array lengths) AND generated TypeScript interfaces — without the full body. Ideal for large responses. PRIMARY PURPOSE: The main goal of API response analysis is to derive TypeScript type definitions. Always present the generated TypeScript interfaces without being asked — this is the expected output for feature ports and migrations. Base URL: https://api.example.com/v1. AUTONOMOUS CONTEXT RESOLUTION — When the endpoint comes from code analysis (feature-port, migration, Vuex store dispatch, API service file): DO NOT call blindly with missing parameters. First investigate the source code context:
Path params (:id, :slug) — find actual values in component data, props, route params, or hardcoded in the store action
Query params — inspect the Vuex action, API service call, or component for the params/query object passed to the request
Request body — check what payload is dispatched or composed in the action
If a value is purely dynamic (e.g. user-selected at runtime), use a representative test value and document the assumption. The goal is to make a real API call that returns representative data for type extraction.
Inputs: method (required), endpoint (required), body, query, +2 more.
Execute an HTTP request, then extract specific fields using dot-notation paths. Returns only the extracted data. Example: fields ["data.items[].name", "meta.total"]. Base URL: https://api.example.com/v1. AUTONOMOUS CONTEXT RESOLUTION — When the endpoint comes from code analysis (feature-port, migration, Vuex store dispatch, API service file): DO NOT call blindly with missing parameters. First investigate the source code context:
Path params (:id, :slug) — find actual values in component data, props, route params, or hardcoded in the store action
Query params — inspect the Vuex action, API service call, or component for the params/query object passed to the request
Request body — check what payload is dispatched or composed in the action
If a value is purely dynamic (e.g. user-selected at runtime), use a representative test value and document the assumption. The goal is to make a real API call that returns representative data for type extraction.
Inputs: fields (required), method (required), endpoint (required), body, +2 more.
Execute an HTTP request and return the full response (smart-truncated if large). Base URL: https://api.example.com/v1 | Token resolution: 1) project .env.mcp REST_BEARER_TOKEN, 2) MCP config env var, 3) session token via rest_set_token. If none found on 401/403, ask the user for a token.. Responses over 50000 bytes are smart-truncated. Use rest_describe for structure only, or rest_types for TypeScript interfaces. AUTONOMOUS CONTEXT RESOLUTION — When the endpoint comes from code analysis (feature-port, migration, Vuex store dispatch, API service file): DO NOT call blindly with missing parameters. First investigate the source code context:
Path params (:id, :slug) — find actual values in component data, props, route params, or hardcoded in the store action
Query params — inspect the Vuex action, API service call, or component for the params/query object passed to the request
Request body — check what payload is dispatched or composed in the action
If a value is purely dynamic (e.g. user-selected at runtime), use a representative test value and document the assumption. The goal is to make a real API call that returns representative data for type extraction.
Inputs: method (required), endpoint (required), body, query, +1 more.
Set the bearer token for this session (persists until server restart). Token resolution: 1) project .env.mcp REST_BEARER_TOKEN, 2) MCP config env var, 3) session token via rest_set_token. If none found on 401/403, ask the user for a token.
Inputs: token (required).
Execute an HTTP request and generate TypeScript interfaces from the response structure. This is the PRIMARY tool for feature-port and migration workflows — returns clean, ready-to-use TypeScript interfaces. PRIMARY PURPOSE: The main goal of API response analysis is to derive TypeScript type definitions. Always present the generated TypeScript interfaces without being asked — this is the expected output for feature ports and migrations. Base URL: https://api.example.com/v1. AUTONOMOUS CONTEXT RESOLUTION — When the endpoint comes from code analysis (feature-port, migration, Vuex store dispatch, API service file): DO NOT call blindly with missing parameters. First investigate the source code context:
Path params (:id, :slug) — find actual values in component data, props, route params, or hardcoded in the store action
Query params — inspect the Vuex action, API service call, or component for the params/query object passed to the request
Request body — check what payload is dispatched or composed in the action
If a value is purely dynamic (e.g. user-selected at runtime), use a representative test value and document the assumption. The goal is to make a real API call that returns representative data for type extraction.
Inputs: method (required), endpoint (required), body, query, +2 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 5 tools
rest_describe and rest_types have nearly identical purposes (both generate TypeScript interfaces from response structure), causing serious overlap. rest_extract also executes a full request but only returns specific fields, further blurring the lines. Only rest_request and rest_set_token are clearly distinct.
Names follow a consistent verb_noun pattern (rest_set_token, rest_request, rest_describe, rest_types, rest_extract). However, 'rest_types' breaks the verb pattern (it's a verb+noun when 'generate_types' would be clearer), and the verbs are somewhat generic, but overall consistent.
With 5 tools, the count is appropriate for a REST API client MCP server. It covers token management, basic requests, structure discovery, type generation, and field extraction — a reasonable scope. Not over or under.
The tool set covers the main API interaction needs but has notable gaps: there is no tool for batch requests, no explicit schema validation or endpoint discovery without making a call, and no way to list available endpoints. An agent might need to make multiple calls to understand API structure.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Host any HTTP API as a standard MCP server; auto-distribute to 12+ mainstream agent platforms.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
