{"id":34983531,"url":"https://github.com/infobip/infobip-openapi-mcp","last_synced_at":"2026-03-03T18:04:16.511Z","repository":{"id":328131933,"uuid":"1096500786","full_name":"infobip/infobip-openapi-mcp","owner":"infobip","description":"Infobip OpenAPI MCP is a framework for exposing OpenAPI documented HTTP APIs as MCP servers. It is based on Spring AI and made to run as a Spring Boot application. It is powering Infobip's own MCP servers, and you can use it to implement your own MCP servers.","archived":false,"fork":false,"pushed_at":"2026-02-25T14:34:35.000Z","size":1272,"stargazers_count":23,"open_issues_count":3,"forks_count":1,"subscribers_count":1,"default_branch":"main","last_synced_at":"2026-02-25T17:27:21.678Z","etag":null,"topics":["ai-agents","infobip","mcp","openapi","spring","spring-ai","spring-boot","swagger"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/infobip.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-11-14T14:15:26.000Z","updated_at":"2026-02-25T13:57:13.000Z","dependencies_parsed_at":"2026-01-28T15:06:37.024Z","dependency_job_id":null,"html_url":"https://github.com/infobip/infobip-openapi-mcp","commit_stats":null,"previous_names":["infobip/infobip-openapi-mcp"],"tags_count":8,"template":false,"template_full_name":null,"purl":"pkg:github/infobip/infobip-openapi-mcp","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infobip%2Finfobip-openapi-mcp","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infobip%2Finfobip-openapi-mcp/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infobip%2Finfobip-openapi-mcp/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infobip%2Finfobip-openapi-mcp/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/infobip","download_url":"https://codeload.github.com/infobip/infobip-openapi-mcp/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infobip%2Finfobip-openapi-mcp/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30054015,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-03T17:46:22.538Z","status":"ssl_error","status_checked_at":"2026-03-03T17:46:22.036Z","response_time":61,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ai-agents","infobip","mcp","openapi","spring","spring-ai","spring-boot","swagger"],"created_at":"2025-12-27T01:10:34.380Z","updated_at":"2026-03-03T18:04:16.504Z","avatar_url":"https://github.com/infobip.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"# OpenAPI MCP\n\n\u003cimg src=\"https://cdn-web.infobip.com/uploads/2025/05/infobip-logo-horizontal-orange.png\" alt=\"Infobip Logo\" height=\"38\" style=\"display:inline;vertical-align:middle;\"\u003e\n\nOpenAPI MCP is an open-source framework for exposing any [OpenAPI][1]-documented HTTP APIs as [MCP][2] servers. Built on [Spring AI][3] and designed to run as a [Spring Boot][4] application, it's already running in production, powering [Infobip MCP servers][5].\n\nIt's production-tested and ready for you to use in your own projects!\n\n## Features\n\nThe framework is a bridge from the OpenAPI described APIs to MCP servers. Core functionality is mapping HTTP API\noperations (paths and HTTP methods) to MCP tools. This includes a setup step that happens upfront to prepare tool\nmetadata which is presented to AI agents and a runtime step that happens when AI agents invoke tools.\n\nSome of the core features include:\n\n- Adapting OpenAPI specification to work with MCP tools. APIs have more flexibility in their inputs, e.g. they accept\n  path and query parameters, while MCP tools expect to receive all inputs as a single JSON object. The framework will\n  detect these cases and wrap / unwrap inputs accordingly.\n- OpenAPI specification allows advanced features in request schema definitions, such as discriminators for polymorphic\n  models. This is not allowed in pure JSON schema used by MCP, so the framework has a transformation step in which\n  discriminators are resolved and embedded in a way compatible with JSON schema.\n- Mock mode in which MCP server returns examples from the OpenAPI specification instead of making HTTP API calls\n\n\u003e [!IMPORTANT]\n\u003e The OpenAPI MCP framework allows you to expose any HTTP API documented with OpenAPI to LLM agents. Since LLMs will\n\u003e process the API responses it is important that you trust the API won't compromise your users' agents with prompt\n\u003e injections. It is equally important to trust the OpenAPI specification, as it is used as a source of meta-data that is\n\u003e directly provided to LLMs. When exposing your own APIs make sure that responses are secure and can't be used to inject\n\u003e untrusted text that might contain prompt injection. When exposing 3rd party APIs make sure the API itself is trusted,\n\u003e but also that the OpenAPI specification which defines it is equally trusted. When working with 3rd party OpenAPI\n\u003e specifications you can review and store them as a static files inside your application resources. That way you can be\n\u003e sure specifications won't change unexpectedly.\n\n### Authentication\n\nAuthentication and authorization is important for MCP servers, and can be tricky to implement. In case of exposing HTTP\nAPIs as MCP tools the security posture of the API is bases for everything. The OpenAPI MCP framework adapts it to MCP\nspecification in few key ways:\n\n- The framework exposes required `/.well-known` HTTP endpoints. Two of them (`/.well-known/openid-configuration` and\n  `/.well-known/oauth-authorization-server`) are proxied to your [authorization server][5], and one (the\n  `/.well-known/oauth-protected-resource`) is handled by the framework itself.\n- There is the option of supporting authorization checking API endpoint that framework invokes before processing MCP\n  interactions to validate client credentials.\n\nLastly, by delegating authentication to dedicated API endpoint, the framework supports arbitrary auth type, such as\nclassic API key and Basic auth types, in addition to OAuth.\n\nThere are more technical features that enable customizing various behaviors, like:\n\n- OpenAPI filters that can be used to programmatically customize the specification before MCP tool metadata is\n  constructed.\n- [OpenAPI extensions][7] that can be used to customize different aspects of MCP tools, including listing custom OAuth\n  scopes.\n- Several naming strategies are available to customize MCP tool names.\n- API request enrichers that can be used to programmatically customize the API requests that back the tool calls.\n- MCP tool call filters that can be used to customize tool call behavior.\n- A base of [Spring AI][3] external customization options, which framework builds on top of with its own options. See\n  below for a full list.\n\n## Getting Started\n\n### Prerequisites\n\nOpenAPI MCP framework requires Java version 21 of newer, and is based on [Spring Boot][4] `3.5.x` and [Spring AI][3]\n`1.1.x`.\n\n### Installation\n\nYou can install it in your Java project with maven:\n\n```xml\n\n\u003cdependency\u003e\n    \u003cgroupId\u003ecom.infobip.openapi.mcp\u003c/groupId\u003e\n    \u003cartifactId\u003einfobip-openapi-mcp-spring-boot-starter\u003c/artifactId\u003e\n    \u003cversion\u003e0.1.8\u003c/version\u003e\n\u003c/dependency\u003e\n```\n\nor gradle:\n\n```groovy\nimplementation(\"com.infobip.openapi.mcp:infobip-openapi-mcp-spring-boot-starter:0.1.8\")\n```\n\n## Usage\n\nAfter installation enable one of the [server protocols supported by Spring AI][8] with externalized configuration\nproperties. For example, you can enable [stdio transport][9] with a config like this:\n\n```yaml\nspring:\n  ai:\n    mcp:\n      server:\n        type: sync\n        stdio: on\n```\n\n\u003e [!IMPORTANT]\n\u003e Make sure to set the server type to `sync`, as some of the framework features (such as authentication) will not work\n\u003e with the `async` type.\n\nTo expose a remote server using the currently recommended [streamable HTTP transport][10] use this config:\n\n```yaml\nspring:\n  ai:\n    mcp:\n      server:\n        protocol: STATELESS\n```\n\n## Configuration\n\n### OpenApiFilter\n\nYou can implement and register beans of type `com.infobip.openapi.mcp.openapi.filter.OpenApiFilter` to change the\nOpenAPI specification before framework extracts MCP tool meta-data from it. Individual filters can be disabled in\nexternalized configuration with the `infobip.openapi.mcp.filters.[filter-name]` property. For example, to disable the\nbuilt-in filter that removes regex pattern property from OpenAPI schemas set\n`infobip.openapi.mcp.filters.PatternPropertyRemover: false`.\n\n\u003e [!TIP]\n\u003e AI agents perform best with smaller, focused MCP servers. On the contrast, HTTP APIs are ofter large and full of\n\u003e different features. This means we usually need to pick a subset of API operations that will be included as tools.\n\u003e Sometimes we need to also pick a limited subset of input parameters like query parameters or even request body\n\u003e properties. There are two ways to prepare OpenAPI specification for this:\n\u003e\n\u003e 1. You can make a dedicated OpenAPI specification for your MCP servers. This can be done either from scratch, or by\n     transforming the original specification with something like [OpenAPI overlays][12]. This transformation can be\n     automated as part of your CI pipeline. In this case your MCP server will receive the limited-scope specification\n     with only the elements that you selected to expose to AI agents.\n\u003e 2. Alternatively, you can provide MCP server with the original, fully featured specification and narrow down its scope\n     by implementing OpenAPI filters in your application code.\n\u003e\n\u003e Both approaches can be combined.\n\n### Tool NamingStrategy\n\nMCP servers expose functionalities to AI agents as tools. Each tool is identified by a name which is accompanied by a\ndescription. LLMs pick tools to use based on this information, so it is important to make them concise and clear. The\nframework implements several strategies for naming tools:\n\n1. `OperationIdStrategy`, which produces names based on `operationId` from OpenAPI specification.\n2. `SanitizedOperationIdStrategy` which uses `operationId`, but sanitizes it by lowercasing alphanumeric characters and\n   replacing others with underscore.\n3. `EndpointStrategy`, which combines HTTP method and path.\n\nVarious MCP client libraries have different limitations on the maximum tool name length. To accommodate this the\nframework provides `TrimNamingStrategy`, which wraps one of the base strategies and enforces length limits on top of it.\n\nYou can customize tool naming with `infobip.openapi.mcp.tools.naming.strategy` and\n`infobip.openapi.mcp.tools.naming.max-length` external configuration properties. If provided implementations do not meet\nyour needs you can provide your own implementation.\n\n\u003e [!TIP]\n\u003e Many MCP client libraries implement scoping of tool names. Common pattern is to allow client applications to name each\n\u003e MCP server they connect to, and to prepend the server name to names of tools loaded from the server. This means you as\n\u003e MCP server developer do not need to scope your tool names. It is best to keep names short and to the point.\n\n### Tool descriptions\n\nLLMs pick tools based on their names and descriptions. In order for them to be able to do that descriptions of all tools\nfrom all MCP servers that an agent is connected to are loaded into LLM context. This means that tool descriptions need\nto be as short as possible while retaining clarity, but not shorter than that.\n\nThe OpenAPI MCP framework can use few API operation properties to create tool descriptions. It can either take just the\noperation summary, or it can combine it with operation description. The behavior can be controlled with\n`infobip.openapi.mcp.tools.prepend-summary-to-description` externalized configuration property.\n\n### Authentication\n\nMCP defines OAuth as preferred authentication method. The framework aims to make this as easy to implement as possible.\nThere are few considerations when exposing existing APIs:\n\n1. The underlying API must implement the same authentication type as MCP server.\n2. There are few specifics of MCP specification that need to be satisfied for clients to work automatically.\n\nOne of MCP requirements is that first interaction with MCP server that doesn't include valid credentials should be\nrejected; in fact that is what triggers the login flow in MCP clients. However, this interaction is usually not direct\ntool invocation, meaning that the framework does not need to make any API calls to implement tool calls. Since\ncredentials still need to be verified framework needs to invoke some API endpoint which only performs the\nauthentication. This special endpoint, which is not exposed as a tool but is used only in this auth flow, needs to be\ndefined in an externalized configuration property `infobip.openapi.mcp.security.auth.auth-url`. This is needed whenever\nsecurity is enabled. The framework will pass any `Authorization` header from the inbound MCP request to the `auth-url`\nendpoint on the API.\n\n#### OAuth\n\nMCP specification defines a flow for automatic [authorization server discovery][13]. One of the requirements is that MCP\nserver itself should expose few `/.well-known` HTTP endpoints defined by the OAuth specification. Some of these are\nusually implemented by the OAuth authorization server, and the OpenAPI MCP framework can proxy those calls to make it\nmore convenient to expose them from the same server as the rest of MCP features. Some endpoints are implemented and\nexposed directly by the framework, as in acts as OAuth resource server.\n\nOAuth APIs usually rely on scopes for fine-grained access control, and MCP specification allows for this. OpenAPI MCP\nframework takes the OAUth scope information from the provided OpenAPI specification. The framework looks for scopes\neither in standard security properties or in custom operation-level OpenAPI extensions that can be defined in\n`infobip.openapi.mcp.security.auth.oauth.scope-discovery.scope-extensions`. Additionally, fixed, predefined scopes can\nalso be defined with `infobip.openapi.mcp.security.auth.oauth.scope-discovery.mandatory-scopes`.\n\nYou can configure what set from all discovered scopes are requested during login by setting the externalized\nconfiguration property `infobip.openapi.mcp.security.auth.oauth.scope-discovery.calculate-minimal-scopes`. When `NONE`\nis used, which is the default, all discovered scopes are requested. When `GREEDY` is used an optimistic greedy algorithm\npicks a subset of scopes which still covers all operations.\n\n### ApiRequestEnricher\n\nIf you need to customize HTTP requests that the framework is making towards the API you can implement and register beans\nof type `com.infobip.openapi.mcp.enricher.ApiRequestEnricher`. This is a good place to include any meta-data for\nmonitoring or custom tracing that you may need. Framework provides few enrichers out of the box, for example the one\nthat sets the `User-Agent` header to the value defined in externalized configuration property\n`infobip.openapi.mcp.user-agent`.\n\n\u003e [!NOTE]\n\u003e Implementations of API request enrichers should be lightweight and non-critical. The framework will skip enrichers\n\u003e that fail by catching any exceptions and carry on to make the API request. This is why the enricher interface is\n\u003e limited\n\u003e to tweaking Spring's `RestClient.RequestHeadersSpec` and does not provide options to break the flow and prevent the\n\u003e API\n\u003e call from being made.\n\n### ToolCallFilter\n\nYou can implement and register beans of type `com.infobip.openapi.mcp.openapi.tool.ToolCallFilter` to customize the tool\ncall handling behavior. Tool call filters can modify requests before making API calls, as well as API responses before\nreturning them to MCP client. They are also a good place to implement custom observability. Unlike API request\nenrichers, tool call filters can break the processing chain, thus preventing the API call from being made.\n\nThe `com.infobip.openapi.mcp.openapi.tool.RegisteredTool` provides the default implementation of a tool filter which\nmakes the HTTP API call. It is registered with the lowest precedence, so you can preempt it by using any precedence\nhigher than that.\n\n### JSON serialization\n\nBoth MCP client libraries and underlying LLMs can sometimes produce invalid JSON documents and send them to MCP server\ntools. The OpenAPI MCP framework implements a helper to address one of the common errors: embedding JSON sub-objects\ninto strings. This is a common failure mode in which a sub-object property of a complex request model is sent to MCP\nserver inside a JSON string. The framework will first send this request to HTTP API as normal, but will likely receive a\nHTTP status code `400` response. In that case framework will attempt to unwrap string property values and look for a\nJSON object or a JSON array inside it. If it detects such a case, it sends another HTTP API requests with the corrected\nrequest body.\n\nYou can disable this behavior by setting externalized configuration property\n`infobip.openapi.mcp.tools.json-double-serialization-mitigation: false`.\n\n### Mock mode\n\nFramework offers a mock mode in which MCP server will return tool call results based on examples from the OpenAPI\nspecification. Framework picks first example for the successful (2xx range) response with `application/json` content\ntype from the API endpoint that corresponds to the tool being called. In case example is missing for the specific\nAPI endpoint an error MCP result is returned. This feature is disabled by default, and can be enabled by setting the\nexternalized configuration property `infobip.openapi.mcp.tools.mock: true`.\n\n\u003e [!NOTE]\n\u003e Even with mock mode enabled, security features still work and will delegate authentication checks to the server \n\u003e defined by the `infobip.openapi.mcp.security.auth.auth-url` property. This allows MCP client implementors to test\n\u003e authentication configuration on their end, including OAuth config.\n\u003e \n\u003e If this is not desired you can disable authentication by setting `infobip.openapi.mcp.security.auth.enabled: false`.\n\u003e By disabling auth and enabling mock mode framework won't use API, and all tool calls will receive successful results\n\u003e based on OpenAPI examples.\n\n### Tool Reload\n\nThe framework supports automatic reloading of the OpenAPI specification at runtime. When enabled, the framework\nperiodically fetches the OpenAPI specification and updates the registered MCP tools if changes are detected. This is\nuseful for scenarios where the OpenAPI specification is updated frequently and you want the MCP server to reflect these\nchanges without requiring a restart.\n\nTool reload works by comparing the OpenAPI specification version. When a version change is detected, the framework\ncompares the registered tools with the new specification and:\n- Removes tools that no longer exist in the specification\n- Adds new tools that were introduced in the specification\n- Updates tools that have changed (title, description, or schema)\n- Discovers new OAuth scopes if scope discovery is enabled\n\nAfter detecting changes, connected MCP clients are notified about the tool list changes, and OAuth scopes are rediscovered automatically if scope discovery is enabled.\n\u003e [!NOTE]\n\u003eDue to MCP SDK constraints, notifications are sent after each individual tool modification rather than in batch.\n\nThe framework retries up to `max-retries` times per scheduled execution, but terminates early on the first successful\nreload (whether or not tools changed). Retries only occur when the reload fails (e.g., due to network errors), using\nexponential backoff between attempts. If a refresh is already in progress when the next scheduled execution triggers,\nthat execution is skipped.\n\n**Prerequisites:**\n- Add `@EnableScheduling` to your Spring Boot application configuration\n\n**Configuration example:**\n\n```yaml\ninfobip:\n  openapi:\n    mcp:\n      live-reload:\n        enabled: true\n        cron-expression: \"0 */5 * * * *\"  # Every 5 minutes\n        max-retries: 3\n```\n\n\u003e [!WARNING]\n\u003e The tool reload task runs on Spring's task scheduler thread pool and blocks the thread during execution. By default,\n\u003e Spring uses a single-threaded scheduler. If your application has multiple scheduled tasks and the reload operation\n\u003e takes time (e.g., due to network latency), consider configuring a larger thread pool:\n\u003e ```yaml\n\u003e spring:\n\u003e   task:\n\u003e     scheduling:\n\u003e       pool:\n\u003e         size: 2\n\u003e ```\n\n### Properties\n\n[External configuration properties][11] that can be used to configure framework behavior:\n\n| Property                                                                           | Description                                                                                                                                                                                                                                                                                                                                             | Default        |\n|------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------|\n| `infobip.openapi.mcp.open-api-url`                                                 | URL to the OpenAPI specification. This should point to a valid OpenAPI document (e.g., JSON or YAML).                                                                                                                                                                                                                                                   | `-`            |\n| `infobip.openapi.mcp.api-base-url`                                                 | Base URL for API endpoints. Supports three formats: **String URL** (e.g., `https://api.example.com`) - use the provided URL directly; **Integer** (e.g., `0`, `1`) - use the i-th server from OpenAPI servers array (0-indexed); **Empty/not provided** - use the first server from OpenAPI servers array.                                              | First server from OpenAPI spec |\n| `infobip.openapi.mcp.connect-timeout`                                              | Connection timeout for HTTP requests to the downstream API. The default is set to 5 seconds.                                                                                                                                                                                                                                                            | 5 seconds      |\n| `infobip.openapi.mcp.read-timeout`                                                 | Read timeout for HTTP requests to the downstream API. The default is set to 5 seconds.                                                                                                                                                                                                                                                                  | 5 seconds      |\n| `infobip.openapi.mcp.user-agent`                                                   | User agent string for HTTP requests to the downstream API. If not specified, no User-Agent header will be set.                                                                                                                                                                                                                                          | `openapi-mcp`  |\n| `infobip.openapi.mcp.filters.[filter-name]`                                        | Filters to apply to the OpenAPI specification. This can be used to include or exclude specific operations or tags. The keys are the filter names, and the values are booleans indicating whether to include (true) or exclude (false). By default, all filters are enabled.                                                                             | `* -\u003e true`    | \n| `infobip.openapi.mcp.tools.naming.strategy`                                        | The naming strategy to use for generating tool names. Default is SANITIZED_OPERATION_ID.                                                                                                                                                                                                                                                                | `ENDPOINT`     | \n| `infobip.openapi.mcp.tools.naming.max-length`                                      | Maximum length for tool names. If specified, names will be trimmed to this length. Must be positive if provided.                                                                                                                                                                                                                                        | `-`            | \n| `infobip.openapi.mcp.tools.schema.parameters-key`                                  | The key name used to wrap parameters in combined schemas. Default is \"_params\".                                                                                                                                                                                                                                                                         | `_params`      | \n| `infobip.openapi.mcp.tools.schema.request-body-key`                                | The key name used to wrap request body in combined schemas. Default is \"_body\".                                                                                                                                                                                                                                                                         | `_body`        | \n| `infobip.openapi.mcp.tools.json-double-serialization-mitigation`                   | Whether to enable automatic JSON double serialization mitigation.                                                                                                                                                                                                                                                                                       | `true`         | \n| `infobip.openapi.mcp.tools.prepend-summary-to-description`                         | Whether to prepend the operation summary as a markdown title to the description.                                                                                                                                                                                                                                                                        | `true`         | \n| `infobip.openapi.mcp.tools.mock`                                                   | Whether to run MCP server in mock mode, where it avoids calling API during tool calls and instead returns results based on examples provided in OpenAPI specification. Default is false.                                                                                                                                                                | `false`        |\n| `infobip.openapi.mcp.live-reload.enabled`                                          | Whether tool reload is enabled. When enabled, the framework periodically fetches the OpenAPI specification and updates registered MCP tools if changes are detected. Requires `@EnableScheduling` on your application.                                                                                                                                  | `false`        |\n| `infobip.openapi.mcp.live-reload.cron-expression`                                  | Cron expression for scheduling OpenAPI specification reload attempts. Uses Spring's cron format (6 fields: second, minute, hour, day-of-month, month, day-of-week). Requires `@EnableScheduling` on your application.                                                                                                                                   | `0 */10 * * * *` |\n| `infobip.openapi.mcp.live-reload.max-retries`                                      | Maximum number of reload attempts per scheduled execution. The loop terminates early on the first successful reload. Retries only occur on failure, using exponential backoff.                                                                                                                                                                          | `3`            |\n| `infobip.openapi.mcp.security.auth.enabled`                                        | Enable API authentication. Default is false.                                                                                                                                                                                                                                                                                                            | `false`        | \n| `infobip.openapi.mcp.security.auth.auth-url`                                       | The API endpoint URL to validate credentials against.                                                                                                                                                                                                                                                                                                   | `-`            |\n| `infobip.openapi.mcp.security.auth.connect-timeout`                                | Connection timeout for the validation API call. Default is 5 seconds.                                                                                                                                                                                                                                                                                   | 5 seconds      |\n| `infobip.openapi.mcp.security.auth.read-timeout`                                   | Read timeout for the validation API call. Default is 5 seconds.                                                                                                                                                                                                                                                                                         | 5 seconds      |\n| `infobip.openapi.mcp.security.auth.override-external-response`                     | Whether to override the external response with the internal one. This is useful for cases where you want to control the response format or content returned to the client. If set to true, the response will be overridden by the model provided by `com.infobip.openapi.mcp.error.ErrorModelProvider`. Default is false.                               | `false`        |\n| `infobip.openapi.mcp.security.auth.oauth.enabled`                                  | Enable OAuth authentication. Default is false.                                                                                                                                                                                                                                                                                                          | `false`        |\n| `infobip.openapi.mcp.security.auth.oauth.url`                                      | OAuth server URL to check for well-known configuration.                                                                                                                                                                                                                                                                                                 | `-`            |\n| `infobip.openapi.mcp.security.auth.oauth.connect-timeout`                          | Connection timeout for the validation API call. Default is 5 seconds.                                                                                                                                                                                                                                                                                   | 5 seconds      |\n| `infobip.openapi.mcp.security.auth.oauth.read-timeout`                             | Read timeout for the validation API call. Default is 5 seconds.                                                                                                                                                                                                                                                                                         | 5 seconds      |\n| `infobip.openapi.mcp.security.auth.oauth.www-authenticate.url-source`              | Value for the WWW-Authenticate header to be used in responses. In case of X_FORWARDED_HOST, the header will be constructed based on the incoming request's X-Forwarded-Host header. If the header is missing, Host header will be used instead, and if that is also missing, the API base URL from configuration will be used. Default is API_BASE_URL. | `API_BASE_URL` |\n| `infobip.openapi.mcp.security.auth.oauth.www-authenticate.include-mcp-endpoint`    | Whether to include the MCP endpoint in the WWW-Authenticate header URL. Default is false.                                                                                                                                                                                                                                                               | `false`        |\n| `infobip.openapi.mcp.security.auth.oauth.scope-discovery.enabled`                  | Enable OAuth scope discovery. Default is true.                                                                                                                                                                                                                                                                                                          | `true`         |\n| `infobip.openapi.mcp.security.auth.oauth.scope-discovery.scope-extensions`         | Scope extensions to read scopes from. Default is an empty string.                                                                                                                                                                                                                                                                                       | `-`            |\n| `infobip.openapi.mcp.security.auth.oauth.scope-discovery.mandatory-scopes`         | Mandatory scopes that must be present. Scopes should be comma-separated. Default is an empty string.                                                                                                                                                                                                                                                    | `-`            |\n| `infobip.openapi.mcp.security.auth.oauth.scope-discovery.calculate-minimal-scopes` | Algorithm for calculating the minimal set of scopes that can access all API endpoints. Two values are supported: NONE, which skips calculation and requests all discovered scopes, and GREEDY which uses a greedy algorithm to find a smaller set of scopes that sill covers all operations. Default is NONE.                                           | `NONE`         |\n\n## Architecture\n\n![Infobip OpenAPI MCP framework architecture](images/architecture.jpg)\n\n### Dependencies\n\nThe framework requires java versions 21 or newer and is compatible with following versions of dependencies:\n\n| Dependency       | Version |\n|------------------|---------|\n| Spring Framework | 6.2.x   |\n| Spring Boot      | 3.5.x   |\n| Spring AI        | 1.1.x   |\n| MCP Java SDK     | 0.16.x  |\n\nFor the complete list of dependencies you can consult the `pom.xml` files.\n\n## Versioning\n\nInfobip OpenAPI MCP framework uses [semantic versioning][14]. In practice this means you should expect breaking changes\nbetween `0.x` releases, such as `0.1.0` -\u003e `0.2.0`. Consult release notes for specific versions for more information.\n\n## License\n\nThis project is licensed under the [MIT License](LICENSE).\n\n---\n\n[1]: https://www.openapis.org \"Landing page fot he OpenAPI specification project\"\n\n[2]: https://modelcontextprotocol.io \"Landing page for the Model Context Protocol\"\n\n[3]: https://spring.io/projects/spring-ai \"Spring AI listing on Spring projects site\"\n\n[4]: https://spring.io/projects/spring-boot \"Spring Boot listing on Spring projects site\"\n\n[5]: https://github.com/infobip/mcp \"GitHub repo with details about Infobip's MCP servers\"\n\n[6]: https://auth0.com/docs/glossary?term=authorization+server \"Authorization server at auth0's OAuth glossary\"\n\n[7]: https://swagger.io/docs/specification/v3_0/openapi-extensions/ \"Guide to OpenAPI extensions\"\n\n[8]: https://docs.spring.io/spring-ai/reference/api/mcp/mcp-server-boot-starter-docs.html#_server_protocols \"Server protocols section in Spring AI documentation\"\n\n[9]: https://modelcontextprotocol.io/specification/latest/basic/transports#stdio \"stdio transport in MCP documentation\"\n\n[10]: https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#streamable-http \"Streamable HTTP transport in MCP documentation\"\n\n[11]: https://docs.spring.io/spring-boot/3.5/reference/features/external-config.html \"Externalized Configuration section in Spring Boot documentation\"\n\n[12]: https://learn.openapis.org/overlay \"OpenAPI Overlays specification\"\n\n[13]: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-server-discovery \"Authorization Server Discovery on MCP documentation\"\n\n[14]: https://semver.org/ \"Semantic Versioning 2.0 specification\"\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Finfobip%2Finfobip-openapi-mcp","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Finfobip%2Finfobip-openapi-mcp","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Finfobip%2Finfobip-openapi-mcp/lists"}