Skip to main content

Idea: Let FME AI Connectors discover and call MCP tools directly


rsun
Contributor
Forum|alt.badge.img+6

Hi everyone,

An idea came up during the MCP and FME training: could the OpenAIConnector or other FME AI Connectors accept one or more MCP server URLs and handle tool discovery and execution directly?

The workflow I have in mind is:

1. Configure the MCP server connections in the AI Connector, with URLs entered directly or supplied through an FME list attribute or JSON configuration.
2. Have the connector discover the available tools and their descriptions and input schemas from each server.
3. Let the AI choose the appropriate tool for the user's prompt and generate arguments that match the tool's JSON input schema.
4. Have the connector call the tool on the correct server, pass the result back to the AI, and continue with additional calls when needed before returning the final response.

In the training, we discussed using MCPCallers to list tools, combining those tool lists, and carrying the server information through attributes to route downstream calls. That is useful, but I would love to have this discovery and routing handled inside the AI Connector so there is less setup to repeat in each workspace.

For example, I could connect two MCP servers, provide a prompt, and let the AI discover which tools are available, choose the right one, build valid arguments, and use the result—all within the connector's configured limits. Will also need to be able to handle multiple authentications for MCP servers requiring that.

This could reduce the number of transformers and manual attribute/JSON management needed for dynamic MCP tool calls, lower the learning curve, and make it easier to try new MCP servers without rebuilding the workspace around their tool lists.

Useful controls could include an allowed-tools list, a maximum number of tool calls, and logs showing the selected server, tool, arguments, and result.

Is this already possible through an existing connector configuration, or is it something being considered for a future release? I'd also be interested to hear whether others in the AI SIG would find this useful.

Cheers,
Reno

2 replies

PierreAtSafe
Safer
Forum|alt.badge.img+11

Hi Reno!

This is actually mostly possible today with the OpenAIConnector. This is the newer connector using the Responses API. You can configure MCP Connections directly in the connector, then select the tools you want to use for your query (or let the AI Model decide). Adding a brief screenshot so you can see an example as I was checking on this feature this morning.

See the help page here (Action > Create Response > Tools > Model Context Protocol): https://docs.safe.com/fme/2026.3/html/FME-Form-Documentation/FME-Transformers/Transformers/pkg-openaiconnector/openaiconnector-pkg.htm

 

Regarding this sentence:

Useful controls could include an allowed-tools list, a maximum number of tool calls, and logs showing the selected server, tool, arguments, and result.

I believe everything you want to log should be outputted by the model and available in the _output{} port. The missing piece would be a maximum number of tool calls. I’ll capture it as a potential improvement for a future release, but I would have to check if the API supports it.

We are still developing connectors for other AI services (Copilot 😉 and Gemini coming soon) and will use the same capabilities if possible with those different APIs.

Cheers,


rsun
Contributor
Forum|alt.badge.img+6
  • Author
  • Contributor
  • October 2, 2026

Hi ​@PierreAtSafe,

Thank you, Pierre — this is excellent news.

The OpenAIConnector support for the Responses API and direct MCP connections is exactly the capability I was hoping for. I also hope FME can eventually offer a model-agnostic option for organizations running local or sovereign AI models—for example, an AI/MCP HTTPCaller-style transformer that provides reusable building blocks regardless of the underlying model or provider.

Being able to select MCP tools within the transformer, with the model output available through the `_output{}` port, should make AI-enabled workflows much more practical and transparent.

For Canadian local governments, a key requirement will be ensuring AI-related ETL and automation can meet Canadian data-residency, privacy, and personal-information protection requirements. This is especially important where workflows may involve resident, property, operational, or other sensitive municipal data.

The planned Copilot connector should provide significant value for many Canadian municipalities. It would also be great to see native support for Cohere and GovAI in the future, particularly where Canadian data sovereignty & privacy are priorities.

Thank you as well for capturing a maximum tool-call limit as a potential enhancement. That type of control would be valuable for predictable execution, cost management, and auditability!

Cheers,

Reno