REST API Gateway MCP Adapter

Synopsis

• This module deploys the 'Model Context Protocol Server' component, which furnishes LLMs with access to predefined, RESTful web services.
• It empowers large language models to interface directly with external APIs, executing standard HTTP interactions based on user directives.
• Current supported transmission methods encompass GET, PUT, POST, and PATCH.

Setup Instructions

• Install the required package: bash pip install openapi_mcp_server

• Generate a configuration file named .env in your working directory, ensuring definition of OPENAPI_SPEC_PATH and API_BASE_URL. A template example is provided here.

• Initiate the service using the command: uv run openapi_mcp_server executed from the directory containing the .env file.

Claud Desktop Integration

• Configuration snippet for Claud Desktop environments:

{ "mcpServers": { "openapi_mcp_server":{ "command": "uv", "args": ["run","openapi_mcp_server"] "env": { "DEBUG":"1", "API_BASE_URL":"https://petstore.swagger.io/v2", "OPENAPI_SPEC_PATH":"https://petstore.swagger.io/v2/swagger.json", "API_HEADERS":"Accept:application/json", "API_WHITE_LIST":"addPet,updatePet,findPetsByStatus" } } } }

Configuration Parameters

• Environmental variables recognized by the adapter:
• DEBUG: Toggles verbose logging output (Boolean representation, defaults to False).
• OPENAPI_SPEC_PATH: URI pointing to the OpenAPI (Swagger) definition document. (Mandatory)
• API_BASE_URL: The root address for all outgoing API requests. (Mandatory)
• API_HEADERS: Custom HTTP headers to be appended to all requests (Optional).
• API_WHITE_LIST: A comma-separated list of specific operationId values permitted for invocation (Optional).
• API_BLACK_LIST: A comma-separated list of specific operationId values explicitly prohibited (Optional).
• HTTP_PROXY: Configuration details for routing HTTP traffic via a proxy server (Optional).
• HTTPS_PROXY: Configuration details for routing HTTPS traffic via a proxy server (Optional).
• NO_PROXY: List of hostnames or domains that should bypass proxy routing (Optional).

Developer Contributions

We welcome external submissions. Kindly submit a Pull Request for review.

Licensing

This software is distributed under the terms of the MIT license.

Repository Popularity

Appendices

UV Package Manager Workflow

bash mkdir -m777 openapi_mcp_server cd openapi_mcp_server uv init uv add mcp[cli] pydantic python-dotenv requests uv add --dev twine setuptools uv sync uv run openapi_mcp_server uv build pip install --force-reinstall --no-deps .\dist\openapi_mcp_server-fileversion.whl export TWINE_USERNAME="rahgadda" export TWINE_USERNAME="<>" uv run twine upload --verbose dist/*

Historical Context

• UV Documentation WIKIPEDIA: XMLHttpRequest (XHR) denotes an Application Programming Interface implemented as a JavaScript object, facilitating the transmission of HTTP queries from a browser environment to a remote web server. Its methods permit web applications to submit server requests subsequent to page loading completion and subsequently retrieve data. XHR forms a fundamental element of Ajax-based development practices. Before Ajax gained prominence, conventional server interaction relied predominantly on hyperlink navigation and HTML form submission, often resulting in a full-page reload.

== Chronology == The genesis of the XMLHttpRequest concept traces back to the year 2000, originating with developers associated with Microsoft Outlook. This paradigm was subsequently integrated into Internet Explorer 5 (released in 1999). Notably, the initial implementation did not utilize the XMLHttpRequest identifier; instead, developers relied on ActiveXObject("Msxml2.XMLHTTP") and ActiveXObject("Microsoft.XMLHTTP"). By the time Internet Explorer 7 (2006) was released, universal browser support for the standard XMLHttpRequest identifier was established. The XMLHttpRequest identifier has since become the established convention across major browser engines, including Mozilla's Gecko (2002), Safari 1.2 (2004), and Opera 8.0 (2005).

=== Standardization Efforts === The World Wide Web Consortium (W3C) formally published a Working Draft specification for the XMLHttpRequest object on April 5, 2006. On February 25, 2008, the W3C issued the Level 2 specification draft. Level 2 introduced expanded capabilities such as event progress monitoring, support for cross-origin requests, and handling of raw byte streams. By the conclusion of 2011, the Level 2 specification provisions were integrated back into the primary specification document. Toward the end of 2012, stewardship of development transitioned to the WHATWG, which currently maintains a dynamic document utilizing Web IDL definitions.

== Operational Procedure == Executing a server request using XMLHttpRequest typically involves several sequential programming stages:

1. Instantiation of an XMLHttpRequest object via its constructor call:
2. Invocation of the "open" method to define the request type, specify the target resource URI, and select either synchronous or asynchronous execution mode:
3. For asynchronous operations, registration of a listener function designed to handle notification upon changes in the request's status:
4. Commencement of the actual data transfer process by calling the "send" method:
5. Continuous monitoring and response handling within the registered event listener. Upon successful server transmission, the response data is typically stored in the "responseText" attribute. When processing concludes, the state transitions to 4, signifying the "done" status. Beyond these fundamental steps, XMLHttpRequest offers extensive customization for controlling request dispatch and response interpretation. Custom header fields can be injected to guide server behavior, and payload data can be supplied directly within the "send" argument. Server responses can be automatically deserialized from JSON format into native JavaScript objects, or processed incrementally as data streams in, obviating the need to wait for the full transmission. Furthermore, the operation can be terminated prematurely or configured to time out if completion is not achieved within a set duration.

== Inter-Domain Communication (Cross-domain requests) ==

In the nascent era of the World Wide Web, limitations were encountered concerning the ability to brea