[Agent Builder] MCP connector #240893

ppisljar · 2025-10-27T20:17:40Z

Summary

This PR implements Model Context Protocol (MCP) support in Kibana using the connector framework with full
Agent Builder integration. MCP connectors enable Kibana agents to access external tools from MCP-compliant
servers, expanding agent capabilities beyond built-in tools.

Key Highlights:

New .mcp connector type
Full Agent Builder integration with tool discovery and execution
Secure authentication with proper credential encryption (fixed security vulnerability)
Tool List caching

Related Work

[Inference] POC: MCP Connector #219733: Original MCP connector POC by @dgieselaar
- Provided foundation for MCP protocol implementation
- Basic HTTP communication and tool operations

Future Work (Not in This PR)

OAuth Authentication: OAuth 2.0 with PKCE support (Plan 003)

Screenshots

Summary: MCP connector support to Kibana, enabling Agent Builder agents to leverage external
tools from MCP servers.

…no-cache --fix'

pgayvallet

Overall approach looks fine to me.

Bunch of questions and other things though

pgayvallet · 2025-10-28T08:36:07Z

x-pack/platform/packages/shared/kbn-mcp-connector-common/README.md

@@ -0,0 +1,3 @@
+# @kbn/mcp-connector-common
+
+Empty package generated by @kbn/generate


NIT: dummy readme content

pgayvallet · 2025-10-28T09:03:14Z

x-pack/platform/packages/shared/kbn-mcp-connector-common/src/namespaces.test.ts

+      expect(isMcpToolId('mcp.github.get_issues')).toBe(true);
+      expect(isMcpToolId('mcp.slack.send_message')).toBe(true);
+      expect(isMcpToolId('mcp.my-connector.tool-name')).toBe(true);


We need to block the mcp. prefix for user-created tools - having gone through the PR I don't think we are

kibana/x-pack/platform/packages/shared/onechat/onechat-common/tools/tool_ids.ts

Lines 24 to 38 in 6105084

/**

* Validate that a tool id has the right format,

* returning an error message if it fails the validation,

* and undefined otherwise.

*

* @param toolId: the toolId to validate

* @param builtIn: set to true if we're validating a built-in (internal) tool id.

*/

export const validateToolId = ({

toolId,

builtIn,

}: {

toolId: string;

builtIn: boolean;

}): string | undefined => {

pgayvallet · 2025-10-28T09:19:29Z

x-pack/platform/plugins/shared/onechat/server/services/agents/persisted/client/client.ts

+      profileUpdate.configuration.tools = await this.validateAgentToolSelection(
+        profileUpdate.configuration.tools,
+        { autoFilter: true }
+      );


What are we trying to do exactly here? Is this meant to be to remove old MCP tools or something?

Why only on update and not on create?

this is for the case where agent was given access to some tools that are no longer there (someone deleted the connector)

i think we'll be able to remove this as @jedrazb addressed this already

pgayvallet · 2025-10-28T09:22:50Z

x-pack/platform/plugins/shared/onechat/server/services/tools/mcp/converter.ts

+
+  return {
+    id: provider.id,
+    type: ToolType.builtin,


I think we want a dedicated mcp tool type.

pgayvallet · 2025-10-28T09:24:18Z

x-pack/platform/plugins/shared/onechat/server/services/tools/mcp/converter.ts

+    type: ToolType.builtin,
+    description: description || `Tool: ${name}`,
+    readonly: true,
+    tags: ['mcp', `connector:${connectorId}`],


NIT: should we use the provider name instead of the connectorId here? Those are uuids which are quite ugly displayed as tags. We can also just remove the connector:xxx tag.

pgayvallet · 2025-10-28T09:38:18Z

x-pack/platform/plugins/shared/onechat/server/services/tools/mcp/mcp_provider.ts

+async function listAllMcpTools({
+  actionsClient,
+  logger,
+}: {
+  actionsClient: ActionsClient;
+  logger: Logger;
+}): Promise<InternalToolDefinition[]> {


This is fine an initial approach, but as discussed we gonna want something slightly more robust later, like som active sync of the connector/tools list to avoid resolving them at every request.

Maybe just some naive caching around the calls to discoverToolsFromConnector with a Xmins TTL could already go a long way?

EDIT: saw the cache at the connector level - which I think is fine for now - can forget about this

i think we want cache on the connector level so everyone can benefit from it.

pgayvallet · 2025-10-28T09:47:29Z

x-pack/platform/plugins/shared/onechat/server/services/tools/tool_registry.ts

 class ToolRegistryImpl implements ToolRegistry {
  private readonly persistedProvider: WritableToolProvider;
  private readonly builtinProvider: ReadonlyToolProvider;
+  private readonly mcpProvider?: ReadonlyToolProvider;


NIT: why optional (looking at the service it's always provided, isn't it?)

pgayvallet · 2025-10-28T10:03:46Z

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/mcp/mcp_connector.ts

+
+  private connected: boolean = false;
+
+  private cachedTools: ListToolsResponse | null = null; // Instance cache


FMI - Have you tested it, does it actually work that way? I always thought the connector instance was re-created for every sub action call? But given that class registers the sub actions, I realize I was probably wrong.

i found this pattern in crowdstrike connector, i didnt test this much yet, but from the logs it looked like its not firing tool discovery requests at every conversation round.

pgayvallet · 2025-10-28T10:07:46Z

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/mcp/mcp_connector.ts

+    this.registerSubAction({
+      method: 'listTools',
+      name: 'listTools',
+      schema: null,
+    });


If we think we're fine with that in-connector cache approach (and it sounds okay for now), then I would add a parameter to the listTools subaction to force a cache clear, wdyt?

lets defer this until needed ?

actually i'll add this as it helps me test the flow

pgayvallet · 2025-10-28T10:12:42Z

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/mcp/mcp_connector.ts

+    const transport = new StreamableHTTPClientTransport(new URL(service.http.url), {
+      requestInit: {
+        headers,
+      },
+    });
+
+    await this.client.connect(transport);


My gut feeling tells me that this connect logic is too simple, that keeping the client open is a bit naive, and that we should probably close it after some time, and at least handle reconnects (if the server terminates the connection on their side, atm this explodes, no?)

what i wanted to do is connect everytime we need to request tool list (so it should not be keeping the connection open). so it should actually only connect when cache is missed and then get the tool list and close the connection (so no need for complex connection management) ....

possibly i messed this up, will take a look and also do some more testing,

i tested this and it works as expected, connections are always recreated/closed, no long running connections

adcoelho · 2025-10-31T09:57:50Z

Since this is a new connector type, the PR should be split into 2 according to the intermediate release process.

There is an example here for the Jira Service Management Connector:

Backend PR - [ResponseOps][Connectors] Jira Service Management Connector phase 1 #231155
Frontend PR - [ResponseOps][Connectors] Jira Service Management Connector phase 2 #235408

You can reach out in #kibana-alerting for more info 🙌

… agentbuilder/mcp_connector

elasticmachine · 2025-11-05T14:18:30Z

💔 Build Failed

Buildkite Build
Commit: b8934e4

Failed CI Steps

History

dgieselaar and others added 8 commits October 27, 2025 05:54

[Inference] POC: MCP Connector

e47b0f4

Refactoring

5a40df2

improve auth...

ffa9725

agent builder integration

c91f355

Auth UI

1db7606

cleanup

c132390

caching

d20c7cd

cleanup

b1f981d

ppisljar added backport:skip This PR does not require backporting release_note:feature Makes this part of the condensed release notes v9.3.0 labels Oct 27, 2025

kibanamachine and others added 9 commits October 27, 2025 20:28

[CI] Auto-commit changed files from 'node scripts/lint_packages --fix'

47d0875

[CI] Auto-commit changed files from 'node scripts/yarn_deduplicate'

e58b363

[CI] Auto-commit changed files from 'node scripts/generate codeowners'

796f39a

[CI] Auto-commit changed files from 'node scripts/eslint_all_files --…

1c2e3d7

…no-cache --fix'

ts fix

3cf945f

ts fix

3f5e5a5

remove ai infra changes

00e083d

Merge branch 'main' into agentbuilder/mcp_connector

4316bfb

fix translations

6d26853

pgayvallet reviewed Oct 28, 2025

View reviewed changes

pr review feedback

e3ac428

ppisljar force-pushed the agentbuilder/mcp_connector branch from 968e1ab to e3ac428 Compare October 30, 2025 14:32

ppisljar added 3 commits October 30, 2025 15:37

Merge branch 'main' into agentbuilder/mcp_connector

31cb147

...

02deb5b

removing test connection button

64b6561

ppisljar marked this pull request as ready for review October 30, 2025 15:46

ppisljar requested review from a team as code owners October 30, 2025 15:46

Changes from node scripts/lint_ts_projects --fix

6383a37

ppisljar and others added 5 commits November 4, 2025 08:04

fix tests

fd00f66

Merge remote-tracking branch 'origin/agentbuilder/mcp_connector' into…

47ac13f

… agentbuilder/mcp_connector

Changes from node scripts/lint_ts_projects --fix

aa77812

view tool

98395f5

Merge branch 'main' into agentbuilder/mcp_connector

b8934e4

		@@ -0,0 +1,3 @@
		# @kbn/mcp-connector-common

		Empty package generated by @kbn/generate

	/**
	* Validate that a tool id has the right format,
	* returning an error message if it fails the validation,
	* and undefined otherwise.
	*
	* @param toolId: the toolId to validate
	* @param builtIn: set to true if we're validating a built-in (internal) tool id.
	*/
	export const validateToolId = ({
	toolId,
	builtIn,
	}: {
	toolId: string;
	builtIn: boolean;
	}): string \| undefined => {


		private connected: boolean = false;

		private cachedTools: ListToolsResponse \| null = null; // Instance cache

[Agent Builder] MCP connector #240893

Are you sure you want to change the base?

[Agent Builder] MCP connector #240893

Conversation

ppisljar commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pgayvallet left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pgayvallet Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pgayvallet Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adcoelho commented Oct 31, 2025

Uh oh!

elasticmachine commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

💔 Build Failed

Failed CI Steps

History

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

ppisljar commented Oct 27, 2025 •

edited

Loading

pgayvallet Oct 28, 2025 •

edited

Loading

pgayvallet Oct 28, 2025 •

edited

Loading

elasticmachine commented Nov 5, 2025 •

edited

Loading