MCP

resolve ai supports integrations with various mcp servers (both remote hosted or self hosted) mcp server requirements resolve ai discovers and invokes tools on mcp servers using the standard https //modelcontextprotocol io/docs/concepts/tools your mcp server must implement the following two json rpc methods tools/list — tool discovery resolve ai calls tools/list to discover which tools the mcp server exposes this is called when the integration is first connected and periodically thereafter if tools/list fails or returns an empty list, the integration will appear unhealthy and no tools will be available { "jsonrpc" "2 0", "id" 1, "method" "tools/list", "params" {} } the response must return an array of tool definitions resolve ai uses three fields from each tool definition name (required) — unique identifier for the tool description (required) — human readable description of what the tool does resolve ai injects this into agent prompts to decide which tools to call during an investigation inputschema (recommended) — json schema object defining expected parameters if omitted, defaults to an empty object schema other mcp spec fields ( title , outputschema , annotations ) are accepted but not currently used by resolve ai tools/call — tool invocation resolve ai calls tools/call to invoke a specific tool with arguments { "jsonrpc" "2 0", "id" 2, "method" "tools/call", "params" { "name" "get weather", "arguments" { "location" "new york" } } } the response must follow the standard mcp tools/call format https //modelcontextprotocol io/docs/concepts/tools#calling tools hosting for mcp servers mcp servers must be remotely hosted to integrate with resolve ai provider hosting some observability or data source platforms host mcps and expose a url to connect to examples linear mcp, atlassian mcp please note resolve ai keeps an allowlist of trusted mcp servers to prevent customers from connecting to malicious mcp servers if an mcp server needs to be added to the allowlist, please reach out to our support team self hosting you can host your own mcp server in your environment and connect it to resolve ai via the https //docs resolve ai/resolve satellite the server just needs to implement the tools/list and tools/call methods described above authentication for mcp servers mcp supports different forms of authentication method authmethod value description token token bearer token authentication the token is sent as authorization bearer \<token> oauth oauth oauth 2 0 flow only supported for publicly accessible mcp integrations create a service account for shared organization access oidc oidc client credentials with an external oidc provider (e g , microsoft entra) custom custom custom header based authentication you control the header name and value none none no authentication important authmethod must be one of these exact values token , oauth , oidc , custom , none if omitted, authmethod defaults to token integrating with resolve ai publicly accessible mcps log in to resolve ai and connect from the integrations page https //app resolve ai/integrations/mcpintegration/connect self hosted in vpc install the https //docs resolve ai/resolve satellite , then configure the mcpintegration in the satellite values yaml file configuration reference integrations \<integration name> # unique name for this integration type mcpintegration create true connection mcpserverurl \<string> # required mcp server url (e g , http //mcp grafana default svc cluster local 8000/sse) authmethod \<enum> # one of token, oidc, custom, none default token token \<string> # required when authmethod is "token" the bearer token value (without "bearer " prefix) toolcalltimeoutms \<number> # optional timeout for mcp tool calls in ms default 30000, max 300000 oidcauthdata # required when authmethod is "oidc" clientid \<string> clientsecret \<string> externaloidcproviderurl \<string> # token endpoint url externaloidcparameters # optional microsoftentraapplicationid \<string> # for microsoft entra scope resolution scope \<string> audience \<string> customauthdata # required when authmethod is "custom" headername \<string> # http header name (e g , authorization, x api key) authschema \<string> # jsonpath to resolve the header value (e g , $ token) secret # inline secrets — helm creates a k8s secret automatically \<key> \<value> # each key becomes a file in the mounted secret directory secretname \<string> # alternative reference a pre existing k8s secret by name how secrets work there are two ways to provide secrets for satellite managed mcp integrations method when to use secret block helm automatically creates a k8s secret and mounts it simplest approach secretname references a k8s secret that already exists in the cluster use when managing secrets externally (e g , via vault, external secrets operator) do not use both secret and secretname for the same integration if neither is provided, no secrets are available at runtime how it works under the hood the helm chart creates a k8s secret from the secret block, mounts it as files at /etc/secrets/\<integration name>/ , and the satellite reads those files at runtime each key in the secret block becomes a file, and the file content becomes the secret value at runtime, these secrets are merged into the connection object as top level properties, making them available via jsonpath for customauthdata authschema (e g , $ token resolves to the value of the token key from the secret) auth method examples token authentication the simplest approach for bearer token auth the satellite automatically sends authorization bearer \<token> integrations my mcp server type mcpintegration create true connection mcpserverurl http //mcp server internal 8000/sse authmethod token token "my secret token value" oidc (client credentials) use for mcp servers that authenticate via an external oidc provider (e g , microsoft entra) the satellite obtains and refreshes tokens automatically using the client credentials grant integrations my mcp server type mcpintegration create true connection mcpserverurl http //mcp server internal 8000/sse authmethod oidc oidcauthdata clientid "my client id" clientsecret "my client secret" externaloidcproviderurl "https //login microsoftonline com/{tenant id}/oauth2/v2 0/token" externaloidcparameters # optional microsoftentraapplicationid "my app id" # for microsoft entra scope resolution scope "custom scope" # for non microsoft providers audience "my audience" custom authentication use when you need full control over the header name and value (e g , non bearer schemes, api keys, or custom headers) integrations my mcp server type mcpintegration create true connection mcpserverurl http //mcp server internal 8000/sse authmethod custom customauthdata headername authorization authschema "$ token" # jsonpath to resolve the header value secret token "bearer my secret token value" authschema is a jsonpath expression resolved against the connection object at runtime, secrets are merged into the connection object, so $ token resolves to the value of the token key from the secret block you can also use secretname to reference a pre existing k8s secret instead — see docid\ pfwvr4 4g ra2ihid5ew3 oauth oauth is configured through the resolve ai ui when connecting a publicly accessible mcp server the oauth flow (authorization, token exchange, refresh) is managed automatically — no satellite configuration is needed no authentication integrations my mcp server type mcpintegration create true connection mcpserverurl http //mcp server internal 8000/sse authmethod none deployment notes after changing the integration configuration in values yaml run helm upgrade to apply the changes ensure the satellite pod restarts (the k8s secret and configmap are only re mounted on pod restart) once configured, the integration will appear on the https //app resolve ai/integrations/mcpintegration/edit and should be marked as healthy