Provides REST API client functionality for interacting with GitHub's API, supporting endpoint discovery through OpenAPI documentation and authenticated requests for managing repositories, issues, and other GitHub resources.
Enables automatic endpoint discovery and documentation parsing from OpenAPI/Swagger specifications, allowing dynamic exploration and interaction with any REST API that provides Swagger documentation.
Click on "Install 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., "@MCP REST Server configure with baseUrl https://api.github.com and token auth, then get my user profile"
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 Model Context Protocol (MCP) server that provides REST API client functionality with authentication support and Swagger documentation integration.
Multiple Authentication Methods: Support for both token-based and login-based authentication
Swagger Integration: Automatic endpoint discovery and documentation from OpenAPI/Swagger specs
Automatic Token Management: Handles token refresh and re-authentication
Comprehensive HTTP Methods: Support for GET, POST, PUT, DELETE, and PATCH requests
Error Handling: Robust error handling with retry logic
MCP Compatible: Fully compatible with the Model Context Protocol
Related MCP server: Swagger/Postman MCP Server
npm install
npm run buildnpm run devThe server supports two authentication methods:
{
"baseUrl": "https://api.example.com",
"swaggerUrl": "https://api.example.com/swagger.json",
"auth": {
"type": "token",
"token": "your-api-token-here"
},
"timeout": 30000,
"retries": 3
}{
"baseUrl": "https://api.example.com",
"swaggerUrl": "https://api.example.com/swagger.json",
"auth": {
"type": "login",
"username": "your-username",
"password": "your-password",
"loginEndpoint": "/auth/login",
"tokenField": "access_token"
},
"timeout": 30000,
"retries": 3
}Configure the REST client with authentication and API details.
Parameters:
baseUrl (required): Base URL for the REST API
auth (required): Authentication configuration (token or login)
swaggerUrl (optional): URL to Swagger/OpenAPI documentation
timeout (optional): Request timeout in milliseconds (default: 30000)
retries (optional): Number of retries for failed requests (default: 3)
Make HTTP requests to the configured API.
Parameters:
method (required): HTTP method (GET, POST, PUT, DELETE, PATCH)
path (required): API endpoint path
params (optional): Query parameters or request body parameters
body (optional): Request body for POST, PUT, PATCH requests
headers (optional): Additional headers
Get the complete list of available endpoints from Swagger documentation.
Search for endpoints in the Swagger documentation.
Parameters:
query (required): Search query to find matching endpoints
Get detailed information about a specific endpoint.
Parameters:
path (required): Endpoint path
method (required): HTTP method
Check if the client is currently authenticated.
Logout and clear authentication state.
Configure the client:
{
"baseUrl": "https://jsonplaceholder.typicode.com",
"auth": {
"type": "token",
"token": "dummy-token"
}
}Make a GET request:
{
"method": "GET",
"path": "/posts/1"
}Make a POST request:
{
"method": "POST",
"path": "/posts",
"body": {
"title": "New Post",
"body": "Post content",
"userId": 1
}
}{
"baseUrl": "https://petstore.swagger.io/v2",
"swaggerUrl": "https://petstore.swagger.io/v2/swagger.json",
"auth": {
"type": "token",
"token": "your-api-key"
}
}Then you can:
Search endpoints: search_endpoints with query "pet"
Get endpoint info: get_endpoint_info with path "/pet" and method "POST"
View all documentation: get_swagger_documentation
Token is stored and used immediately
Added to requests as Authorization: Bearer <token>
If 401 received, no automatic retry (token assumed invalid)
Makes login request to specified endpoint
Extracts token from response using tokenField
Stores token in memory
Adds token to subsequent requests
If 401 received, automatically re-authenticates and retries
Network errors: Automatic retry with exponential backoff
Authentication errors: Automatic re-authentication for login-based auth
Validation errors: Clear error messages with details
API errors: HTTP status and error message forwarding
src/
├── types.ts # TypeScript type definitions
├── auth.ts # Authentication manager
├── swagger.ts # Swagger documentation parser
├── rest-client.ts # REST client implementation
└── index.ts # MCP server implementationnpm run buildnpm startThe MCP REST server now supports automatic configuration through multiple methods, eliminating the need to configure APIs manually for each project.
Command Line Arguments (highest priority)
Environment Variables
Configuration File
Manual Configuration (via MCP tools - lowest priority)
{
"mcpServers": {
"mcp-rest-github": {
"command": "node",
"args": ["/path/to/your/mcp-rest/dist/index.js"],
"env": {
"MCP_REST_BASE_URL": "https://api.github.com",
"MCP_REST_AUTH_TYPE": "token",
"MCP_REST_TOKEN": "your-github-token-here",
"MCP_REST_SWAGGER_URL": "https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json"
}
},
"mcp-rest-petstore": {
"command": "node",
"args": ["/path/to/your/mcp-rest/dist/index.js"],
"env": {
"MCP_REST_BASE_URL": "https://petstore.swagger.io/v2",
"MCP_REST_AUTH_TYPE": "token",
"MCP_REST_TOKEN": "your-api-key",
"MCP_REST_SWAGGER_URL": "https://petstore.swagger.io/v2/swagger.json"
}
}
}
}{
"mcpServers": {
"mcp-rest-github": {
"command": "node",
"args": ["/path/to/your/mcp-rest/dist/index.js", "--config", "/path/to/your/mcp-rest/examples/github-api.json"]
},
"mcp-rest-petstore": {
"command": "node",
"args": ["/path/to/your/mcp-rest/dist/index.js", "--config", "/path/to/your/mcp-rest/examples/petstore.json"]
}
}
}{
"mcpServers": {
"mcp-rest-github": {
"command": "node",
"args": [
"/path/to/your/mcp-rest/dist/index.js",
"--base-url", "https://api.github.com",
"--auth-type", "token",
"--token", "your-github-token-here",
"--swagger-url", "https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json"
]
}
}
}Location:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Use the same configuration options as Cursor above.
The project includes several example configurations in the examples/ directory:
examples/github-api.json - GitHub API configuration
examples/petstore.json - Swagger Petstore API configuration
examples/jsonplaceholder.json - JSONPlaceholder API configuration
Variable | Description |
| Base URL for the REST API (required) |
| Authentication type: 'token' or 'login' (required) |
| API token (required for token auth) |
| Username (required for login auth) |
| Password (required for login auth) |
| Login endpoint path (required for login auth) |
| Token field name in login response (default: access_token) |
| URL to Swagger/OpenAPI documentation |
| Request timeout in milliseconds (default: 30000) |
| Number of retries for failed requests (default: 3) |
| Path to JSON configuration file |
Note: Replace /path/to/your/mcp-rest/ with the actual path to your MCP REST server directory.
If you've configured the server with auto-configuration (environment variables, CLI args, or config file), the server will be ready to use immediately:
Make a GET request to /posts/1
Show me all available endpoints
Search for endpoints related to "user"If you haven't provided auto-configuration, you can still configure the client manually:
Configure the client first:
Please configure the REST client with:
- Base URL: https://api.example.com
- Authentication: token
- Token: your-api-token-here
- Swagger URL: https://api.example.com/swagger.jsonThen make API requests:
Make a GET request to /users/123You can test your configuration before using it in Claude/Cursor:
# Test with config file
node dist/index.js --config examples/jsonplaceholder.json
# Test with CLI arguments
node dist/index.js --base-url https://api.github.com --auth-type token --token your-token
# Test with environment variables
MCP_REST_BASE_URL=https://httpbin.org MCP_REST_AUTH_TYPE=token MCP_REST_TOKEN=test node dist/index.jsIf you see "✅ Auto-configured REST client for [URL]", the configuration is working correctly.
MIT
Check if the client is currently authenticated
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full behavioral disclosure. It fails to specify what constitutes 'authenticated', whether it returns a boolean or throws an error, or if there are side effects. The minimal description adds little transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence with no wasted words, which is appropriate for a simple tool. However, it is very brief and could include more context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return value or output format. Given the tool's simplicity, it should at least indicate that it returns a boolean or status. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to provide parameter details. Schema description coverage is trivially 100%, warranting a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Check' and the resource 'authentication status', clearly indicating the tool's function. However, it does not differentiate from sibling tools like 'logout' or 'http_request', which may also involve authentication state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as before sensitive operations or after login. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure the REST client with base URL, authentication, and optional Swagger documentation URL
| Name | Required | Description | Default |
|---|---|---|---|
| baseUrl | Yes | Base URL for the REST API | |
| swaggerUrl | No | URL to Swagger/OpenAPI documentation (optional) | |
| auth | Yes | ||
| timeout | No | Request timeout in milliseconds (default: 30000) | |
| retries | No | Number of retries for failed requests (default: 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose side effects. It mentions authentication but does not state that login auth may trigger network calls or that configuration persists globally. The description is insufficient for an agent to understand behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the key purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a configuration tool with complex auth options and no output schema, the description is too brief. It does not explain return value, persistence of settings, or prerequisites. An agent would benefit from more detail on how configuration affects subsequent requests.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so description adds some value by summarizing parameters into groups (base URL, auth, Swagger URL). However, it does not elaborate on the auth object's two distinct modes, leaving the agent to infer from schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures a REST client with base URL, authentication, and optional Swagger URL. It distinguishes from siblings like http_request which use the client, but could be more specific about the configuration scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It should indicate that this setup is required before making HTTP requests, but the description is silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Endpoint path | |
| method | Yes | HTTP method |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or side effects. The single sentence is insufficient for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, which is efficient. However, it lacks front-loading of critical details and could be structured to include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal. It does not explain what 'detailed information' entails or how the response is structured, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema's parameter descriptions. No further elaboration on path or method format is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific endpoint', distinguishing it from siblings like 'search_endpoints' (search) and 'get_swagger_documentation' (whole documentation). However, it could be more specific about what 'detailed information' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'search_endpoints' or when not to use it. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete Swagger/OpenAPI documentation for available endpoints
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention that this is a read-only operation, the format of the output (e.g., JSON/YAML), or any potential size or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, highly concise and front-loaded. Every word serves a purpose, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is minimal but adequate for a simple documentation retrieval tool. However, it lacks behavioral details and usage hints, making it barely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so baseline is 4. The description adds no parameter information (none needed), meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the complete Swagger/OpenAPI documentation for available endpoints. The verb 'Get' and resource 'complete Swagger/OpenAPI documentation' are specific, and it distinguishes from siblings like get_endpoint_info which returns a single endpoint's info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_endpoint_info or search_endpoints. It only states what it does, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP request to the configured API
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | HTTP method | |
| path | Yes | API endpoint path | |
| params | No | Query parameters (for GET) or request body parameters | |
| body | No | Request body (for POST, PUT, PATCH) | |
| headers | No | Additional headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not mention side effects, idempotency, authentication needs, rate limits, or error behavior. For a generic HTTP tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is one short sentence with no wasted words. Could include slightly more detail but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 5 params, includes nested objects, and no output schema. Description does not explain return format, error handling, or usage patterns, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; each parameter has a clear description. Description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb, resource, and context: 'Make an HTTP request to the configured API'. Clearly distinguishes from sibling tools like check_authentication or configure_rest_client.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., search_endpoints, get_swagger_documentation). Missing when-not-to-use or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Logout and clear authentication state
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks detail on side effects (e.g., token invalidation, session termination) beyond the vague 'clear authentication state'. No annotations to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise—two words—with no extraneous information. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple, parameterless tool. However, it could mention potential side effects or prerequisites (e.g., must be authenticated).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description cannot add value beyond the schema. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Logout' and the consequence 'clear authentication state', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like check_authentication, but the use case is straightforward and implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for endpoints in the Swagger documentation
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find matching endpoints |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only states it 'searches', but does not disclose whether it is read-only, what the response format is, or any side effects. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 8 words, front-loading the action and resource. Every word is purposeful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal. It does not explain the return format, whether results are paginated, or what fields are returned, leaving the agent with significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description for 'query' is adequate. The tool description adds no extra meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'search' and resource 'endpoints' with scope 'in the Swagger documentation', clearly distinguishing it from siblings like get_endpoint_info (single endpoint details) and get_swagger_documentation (whole document).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_endpoint_info or http_request. The description lacks any context about prerequisites, use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0check_authenticationconfigure_rest_clientget_endpoint_infoget_swagger_documentationhttp_requestlogoutsearch_endpointsEach tool has a distinct purpose: authentication checking, configuration, endpoint info, documentation retrieval, HTTP requests, logout, and endpoint search. No overlap.
All tool names follow the verb_noun snake_case pattern (e.g., check_authentication, get_endpoint_info), ensuring predictability.
7 tools cover the core functionality of a REST client server without being excessive or sparse, aligning well with the server's scope.
The tool set covers authentication lifecycle, API documentation exploration, and HTTP requests. Missing features like configuration management (e.g., updating base URL without reconfiguring) are minor.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Search, document and execute authenticated API calls across 700+ apps via one MCP server
Remote MCP for 1,500+ APIs. Vault-managed credentials; OAuth or API key. Search, load, and execute.
Drive real Android & iOS devices and web browsers from natural language for mobile + web QA. 290+ tools across device control, app management, automation sessions, browser automation, and flow recording / replay. Bearer-auth — get a token at robotactions.com → Profile → API Tokens.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gyuco/mcp-http-client'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
