OpenAPI REST MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| API_USER | No | Jira basic authentication username | |
| EAM_USER | No | HxGN EAM basic authentication username | |
| API_TOKEN | No | Jira basic authentication API token | |
| CLIENT_ID | No | SharePoint (Microsoft Graph) client ID | |
| TENANT_ID | No | SharePoint (Microsoft Graph) tenant ID | |
| EAM_PASSWORD | No | HxGN EAM basic authentication password | |
| CLIENT_SECRET | No | SharePoint (Microsoft Graph) client secret | |
| PRIMAVERA_USER | No | Primavera basic authentication username | |
| ZOHO_CLIENT_ID | No | Zoho OAuth client ID | |
| MCP_SERVER_NAME | No | MCP server name (optional) | |
| PROCORE_CLIENT_ID | No | Procore OAuth client ID | |
| PROCORE_TOKEN_URL | No | Procore OAuth token URL (optional) | https://login-sandbox.procore.com/oauth/token/ |
| CLAUDE_CONFIG_PATH | No | Path to Claude Desktop configuration file (optional, used for Procore token persistence) | |
| PRIMAVERA_PASSWORD | No | Primavera basic authentication password | |
| ZOHO_CLIENT_SECRET | No | Zoho OAuth client secret | |
| ZOHO_REFRESH_TOKEN | No | Zoho OAuth refresh token | |
| SALESFORCE_CLIENT_ID | No | Salesforce OAuth client ID | |
| SALESFORCE_TOKEN_URL | No | Salesforce OAuth token URL | |
| PROCORE_CLIENT_SECRET | No | Procore OAuth client secret | |
| PROCORE_REFRESH_TOKEN | No | Procore OAuth refresh token | |
| SALESFORCE_CLIENT_SECRET | No | Salesforce OAuth client secret |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| api_getC | GET request to an API endpoint |
| api_postC | POST request to an API endpoint |
| api_putC | PUT request to an API endpoint |
| api_deleteC | DELETE request to an API endpoint |
| api_patchB | PATCH request to an API endpoint |
| inspect_loginA | POST credentials to the login endpoint and return the raw response plus suggested token paths. Use this to discover the right auth.tokenPath (and verify auto-discovered loginUrl) without committing config. |
| swagger_fetchC | Fetch and summarize Swagger/OpenAPI documentation for an environment |
| swagger_list_endpointsB | List API endpoints from Swagger. Optionally fuzzy-search by keyword and/or filter by tag and method. |
| swagger_get_endpointC | Get detailed information about a specific endpoint from Swagger |
| swagger_get_schemaC | Get a schema/model definition from Swagger documentation |
| config_statusA | Report where the config is looked for, whether it was found/loaded, the active environment, and the available environments. Use this to diagnose setup issues. |
| config_initA | Write a starter config.json (from config.example.json) so the user can fill it in. Writes to the resolved config path by default; will not overwrite unless force is true. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Tools are mostly distinct: HTTP methods are separate, Swagger exploration tools have clear purposes (summary vs list vs detail vs schema). Minor ambiguity exists between swagger_fetch (summarize docs) and swagger_list_endpoints (list endpoints), but descriptions resolve it.
Most tools follow a resource_action pattern (api_get, swagger_fetch, config_status). inspect_login breaks the pattern by putting the verb first, but the overall convention is still readable and predictable.
12 tools is well within the ideal range for a REST/OpenAPI server, with no redundancy. Each tool serves a distinct need from documentation exploration to HTTP requests and configuration.
The tool surface covers the full workflow: fetching OpenAPI docs, discovering endpoints and schemas, performing all standard HTTP methods, handling login/token discovery, and managing configuration. No obvious dead ends.