[GH-ISSUE #7865] Model Context Protocol (MCP) support #30792

New Issue

GiteaMirror · 2026-04-22T10:42:19-05:00

GiteaMirror commented

2026-04-22 10:42:19 -05:00

Originally created by @itsPreto on GitHub (Nov 27, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/7865

Originally assigned to: @ParthSareen on GitHub.

Model Context Protocol as the name suggests standardizes the external datasource interaction.

the fact that is completely open source opens up the path for faster collaboration/progress imo

Official Github

15-minute-walkthrough-yt

Originally created by @itsPreto on GitHub (Nov 27, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/7865 Originally assigned to: @ParthSareen on GitHub. Model Context Protocol as the name suggests standardizes the external datasource interaction. + the fact that is completely open source opens up the path for faster collaboration/progress imo [Official Github](https://github.com/modelcontextprotocol/) [15-minute-walkthrough-yt](https://github.com/modelcontextprotocol/)

GiteaMirror added the feature request label 2026-04-22 10:42:19 -05:00

GiteaMirror commented

2026-04-22 10:42:20 -05:00

@Rakhsan commented on GitHub (Nov 28, 2024):

+1 should be useful

@Rakhsan commented on GitHub (Nov 28, 2024): +1 should be useful

GiteaMirror commented

2026-04-22 10:42:21 -05:00

@josx commented on GitHub (Nov 28, 2024):

Some technical details for implementation https://glama.ai/blog/2024-11-25-model-context-protocol-quickstart

@josx commented on GitHub (Nov 28, 2024): Some technical details for implementation https://glama.ai/blog/2024-11-25-model-context-protocol-quickstart

GiteaMirror commented

2026-04-22 10:42:21 -05:00

@ptomczyk commented on GitHub (Nov 28, 2024):

This is indeed an interesting topic, but I can't even wrap my head around MCPs. I briefly understand how it's utilised by Claude Desktop, but what would be the possible outcome of "implementing" (integrating?) this protocol into Ollama. What is the potential benefit? I can't even come up with the use case because I'm lost in the details of this. Can someone point me in the right direction of thinking or understanding this as a concept? I'm not asking for explanation of MCP but rather Ollama+MCP.

@ptomczyk commented on GitHub (Nov 28, 2024): This is indeed an interesting topic, but I can't even wrap my head around MCPs. I briefly understand how it's utilised by Claude Desktop, but what would be the possible outcome of "implementing" (integrating?) this protocol into Ollama. What is the potential benefit? I can't even come up with the use case because I'm lost in the details of this. Can someone point me in the right direction of thinking or understanding this as a concept? I'm not asking for explanation of MCP but rather Ollama+MCP.

GiteaMirror commented

2026-04-22 10:42:23 -05:00

@24601 commented on GitHub (Nov 29, 2024):

MCP is very important and impressive and likely will become a dominant standard but it still seems more “ollama adjacent” than core feature of ollama. @ptomczyk I think you’re correct that this isn’t an ollama feature.

Perhaps someone would want an ollama MCP server that would allow hosts (in MCP parlance) to call ollama models or even other models (through a host) to call an ollama model.

But, all in all ollama strictly (beyond providing a very bare convenience CLI) isn’t a “host” (in MCP parlance) and I think isn’t seeking to be.

Supporting those who want to enable ollama to be called by servers makes sense but I’m also not seeing a credible core use case for MCP in-tree to ollama ATM.

@24601 commented on GitHub (Nov 29, 2024): MCP is very important and impressive and likely will become a dominant standard but it still seems more “ollama adjacent” than core feature of ollama. @ptomczyk I think you’re correct that this isn’t an ollama feature. Perhaps someone would want an ollama MCP server that would allow hosts (in MCP parlance) to call ollama models or even other models (through a host) to call an ollama model. But, all in all ollama strictly (beyond providing a very bare convenience CLI) isn’t a “host” (in MCP parlance) and I think isn’t seeking to be. Supporting those who want to enable ollama to be called by servers makes sense but I’m also not seeing a credible core use case for MCP in-tree to ollama ATM.

GiteaMirror commented

2026-04-22 10:42:24 -05:00

@gpertea commented on GitHub (Nov 29, 2024):

👍
The client/host/server terminology is a bit confusing around MCP (for me), but it seems to me that it could be a great benefit for the community if ollama were to also provide a basic working implementation of the MCP protocol as a client (or "host") to be distributed alongside the usual (+chat) API (like Claude desktop chat app does).

I think that could greatly simplify (and standardize the interfacing with) 3rd party chat UI implementations that can make use of new tools/functions (e.g. adding web search to any model that support tool use, and any chat UI etc.) . It would be also a great way to perform local / low cost prototyping while experimenting with various models for robust generic, agent/tool designs using MCP.

Perhaps this could also make it easier for developers to explore/test ways to elevate the functionality of cheap local models to SOTA commercial models' performance - when using MCP-based tools.

@gpertea commented on GitHub (Nov 29, 2024): 👍 The client/host/server terminology is a bit confusing around MCP (for me), but it seems to me that it could be a great benefit for the community if ollama were to also provide a basic working implementation of the MCP protocol as a client (or "host") to be distributed alongside the usual (+chat) API (like Claude desktop chat app does). I think that could greatly simplify (and standardize the interfacing with) 3rd party chat UI implementations that can make use of new tools/functions (e.g. adding web search to any model that support tool use, and any chat UI etc.) . It would be also a great way to perform local / low cost prototyping while experimenting with various models for robust generic, agent/tool designs using MCP. Perhaps this could also make it easier for developers to explore/test ways to elevate the functionality of cheap local models to SOTA commercial models' performance - when using MCP-based tools.

GiteaMirror commented

2026-04-22 10:42:26 -05:00

@anan1213095357 commented on GitHub (Nov 30, 2024):

All along, we've been trying to enhance the capabilities of large models primarily through function calls, but this approach has its limitations. It would be great to have a middleware that can directly interface with databases. Does MCP support database integration? Can it connect to services like web APIs?

@anan1213095357 commented on GitHub (Nov 30, 2024): All along, we've been trying to enhance the capabilities of large models primarily through function calls, but this approach has its limitations. It would be great to have a middleware that can directly interface with databases. Does MCP support database integration? Can it connect to services like web APIs?

GiteaMirror commented

2026-04-22 10:42:26 -05:00

@erodactyl commented on GitHub (Nov 30, 2024):

@anan1213095357 MCP is a more standardized version of function calling. As you can read more about here - it's a way to connect to MCP servers, negotiate capabilities with them (i.e. what functions are available to call from the server) and use those capabilities.

Maybe we can add a few minimal built-in (or somehow added on) functions to Ollama and have a separate software that would act as the MCP client. The function would act as an intermediary to use that MCP client.

I do also believe that having local MCP capabilities would greatly improve what we can do with local LLMs.

@24601 if I understand everything correctly, MCP is a way for LLMs to call external sources, not vice versa. While calling LLMs is very useful, LLMs calling external services in standardized ways like automatic capability negotiation is also crucial, similar to function calling. Edit: I think I now better understand what you meant - someone would create a "host" which would do everything the MCP is supposed to do and use Ollama - similar to Claude desktop app being the host without the model itself, but still connecting all the necessary information and passing it to the model.

@erodactyl commented on GitHub (Nov 30, 2024): @anan1213095357 MCP is a more standardized version of function calling. As you can read more about [here](https://modelcontextprotocol.io/quickstart#whats-happening-under-the-hood) - it's a way to connect to MCP servers, negotiate capabilities with them (i.e. what functions are available to call from the server) and use those capabilities. Maybe we can add a few minimal built-in (or somehow added on) functions to Ollama and have a separate software that would act as the MCP client. The function would act as an intermediary to use that MCP client. I do also believe that having local MCP capabilities would greatly improve what we can do with local LLMs. @24601 if I understand everything correctly, MCP is a way for LLMs to call external sources, not vice versa. While calling LLMs is very useful, LLMs calling external services in standardized ways like automatic capability negotiation is also crucial, similar to function calling. Edit: I think I now better understand what you meant - someone would create a "host" which would do everything the MCP is supposed to do and use Ollama - similar to Claude desktop app being the host without the model itself, but still connecting all the necessary information and passing it to the model.

GiteaMirror commented

2026-04-22 10:42:27 -05:00

@SwePalm commented on GitHub (Nov 30, 2024):

The naming might confuse some people, but if Ollama would implement the open sourced MCP client, then we could use all MCP servers available, which just is a new name / wrapper for tools...but aspire to be implemented in a "standard" way.
Cool thing is that it is pretty easy to build your own MCP server, that could wrap you custom python function to do....whatever you want to add to your LLM. IF this takes off, and we see a community building a ton of MCP servers, Ollama need to integrate a MCP client.
Just think of it as equal to use Langchain tools...-ish.

@SwePalm commented on GitHub (Nov 30, 2024): The naming might confuse some people, but if Ollama would implement the open sourced MCP client, then we could use all MCP servers available, which just is a new name / wrapper for tools...but aspire to be implemented in a "standard" way. Cool thing is that it is pretty easy to build your own MCP server, that could wrap you custom python function to do....whatever you want to add to your LLM. IF this takes off, and we see a community building a ton of MCP servers, Ollama need to integrate a MCP client. Just think of it as equal to use Langchain tools...-ish.

GiteaMirror commented

2026-04-22 10:42:28 -05:00

@ryana commented on GitHub (Nov 30, 2024):

My first thought is that this would actually live inside OpenWebUI. Someone else had the same idea: https://github.com/open-webui/open-webui/discussions/7363

@ptomczyk an ollama native integration would look like something like:

Expect the MCP servers to be running
Have an env var pointing to them
Query the available tools from MCP
Inject the tools automatically server side into all calls
And then this is the tricky part: go into an agent loop calling the tools as needed

imo this would be a big additional set of functionality to add to ollama and may not be philosophically aligned with the initial goals of this project. However, it would be relatively ease to spin up another server in front of ollama which handles this.

@ryana commented on GitHub (Nov 30, 2024): My first thought is that this would actually live inside OpenWebUI. Someone else had the same idea: https://github.com/open-webui/open-webui/discussions/7363 @ptomczyk an ollama native integration would look like something like: 1. Expect the MCP servers to be running 2. Have an env var pointing to them 3. Query the available tools from MCP 4. Inject the tools automatically server side into all calls 5. And then this is the tricky part: go into an agent loop calling the tools as needed imo this would be a big additional set of functionality to add to ollama and may not be philosophically aligned with the initial goals of this project. However, it would be relatively ease to spin up another server in front of ollama which handles this.

GiteaMirror commented

2026-04-22 10:42:29 -05:00

@24601 commented on GitHub (Dec 1, 2024):

@anan1213095357 MCP is a more standardized version of function calling. As you can read more about here - it's a way to connect to MCP servers, negotiate capabilities with them (i.e. what functions are available to call from the server) and use those capabilities.

Maybe we can add a few minimal built-in (or somehow added on) functions to Ollama and have a separate software that would act as the MCP client. The function would act as an intermediary to use that MCP client.

I do also believe that having local MCP capabilities would greatly improve what we can do with local LLMs.

@24601 if I understand everything correctly, MCP is a way for LLMs to call external sources, not vice versa. While calling LLMs is very useful, LLMs calling external services in standardized ways like automatic capability negotiation is also crucial, similar to function calling. Edit: I think I now better understand what you meant - someone would create a "host" which would do everything the MCP is supposed to do and use Ollama - similar to Claude desktop app being the host without the model itself, but still connecting all the necessary information and passing it to the model.

Checkout the sampling and other modes, it’s quite clever and functionally creates bi-directional comms. Someone has even written a server that allows Claude to call OpenAI LLMs. It’s far more than just what you’re describing. It is quite nice and very understatedly named.

@24601 commented on GitHub (Dec 1, 2024): > @anan1213095357 MCP is a more standardized version of function calling. As you can read more about [here](https://modelcontextprotocol.io/quickstart#whats-happening-under-the-hood) - it's a way to connect to MCP servers, negotiate capabilities with them (i.e. what functions are available to call from the server) and use those capabilities. > > Maybe we can add a few minimal built-in (or somehow added on) functions to Ollama and have a separate software that would act as the MCP client. The function would act as an intermediary to use that MCP client. > > I do also believe that having local MCP capabilities would greatly improve what we can do with local LLMs. > > @24601 if I understand everything correctly, MCP is a way for LLMs to call external sources, not vice versa. While calling LLMs is very useful, LLMs calling external services in standardized ways like automatic capability negotiation is also crucial, similar to function calling. Edit: I think I now better understand what you meant - someone would create a "host" which would do everything the MCP is supposed to do and use Ollama - similar to Claude desktop app being the host without the model itself, but still connecting all the necessary information and passing it to the model. Checkout the sampling and other modes, it’s quite clever and functionally creates bi-directional comms. Someone has even written a server that allows Claude to call OpenAI LLMs. It’s far more than just what you’re describing. It is quite nice and very understatedly named.

GiteaMirror commented

2026-04-22 10:42:31 -05:00

@erodactyl commented on GitHub (Dec 1, 2024):

@anan1213095357 MCP is a more standardized version of function calling. As you can read more about here - it's a way to connect to MCP servers, negotiate capabilities with them (i.e. what functions are available to call from the server) and use those capabilities.
Maybe we can add a few minimal built-in (or somehow added on) functions to Ollama and have a separate software that would act as the MCP client. The function would act as an intermediary to use that MCP client.
I do also believe that having local MCP capabilities would greatly improve what we can do with local LLMs.
@24601 if I understand everything correctly, MCP is a way for LLMs to call external sources, not vice versa. While calling LLMs is very useful, LLMs calling external services in standardized ways like automatic capability negotiation is also crucial, similar to function calling. Edit: I think I now better understand what you meant - someone would create a "host" which would do everything the MCP is supposed to do and use Ollama - similar to Claude desktop app being the host without the model itself, but still connecting all the necessary information and passing it to the model.

Checkout the sampling and other modes, it’s quite clever and functionally creates bi-directional comms. Someone has even written a server that allows Claude to call OpenAI LLMs. It’s far more than just what you’re describing. It is quite nice and very understatedly named.

Yes, an LLM can both be a context provider and a context consumer.

So the question still remains, should we implement MCP host in Ollama? Or is it more semantically correct to have another software which wraps Ollama and also acts as an MCP host? Similar to what @ryana suggests for open-webui.

@erodactyl commented on GitHub (Dec 1, 2024): > > @anan1213095357 MCP is a more standardized version of function calling. As you can read more about [here](https://modelcontextprotocol.io/quickstart#whats-happening-under-the-hood) - it's a way to connect to MCP servers, negotiate capabilities with them (i.e. what functions are available to call from the server) and use those capabilities. > > Maybe we can add a few minimal built-in (or somehow added on) functions to Ollama and have a separate software that would act as the MCP client. The function would act as an intermediary to use that MCP client. > > I do also believe that having local MCP capabilities would greatly improve what we can do with local LLMs. > > @24601 if I understand everything correctly, MCP is a way for LLMs to call external sources, not vice versa. While calling LLMs is very useful, LLMs calling external services in standardized ways like automatic capability negotiation is also crucial, similar to function calling. Edit: I think I now better understand what you meant - someone would create a "host" which would do everything the MCP is supposed to do and use Ollama - similar to Claude desktop app being the host without the model itself, but still connecting all the necessary information and passing it to the model. > > Checkout the sampling and other modes, it’s quite clever and functionally creates bi-directional comms. Someone has even written a server that allows Claude to call OpenAI LLMs. It’s far more than just what you’re describing. It is quite nice and very understatedly named. Yes, an LLM can both be a context provider and a context consumer. So the question still remains, should we implement MCP host in Ollama? Or is it more semantically correct to have another software which wraps Ollama and also acts as an MCP host? Similar to what @ryana suggests for open-webui.

GiteaMirror commented

2026-04-22 10:42:31 -05:00

@24601 commented on GitHub (Dec 1, 2024):

@erodactyl definitely a bit of a scope question, I think maintainers and stakeholders probably have to ask themselves the question of scope independent of MCP. As it stands now Ollama can be used with the MCP OpenAI server by pointing it to the Ollama endpoint and as for host, I would think if the core feature work is done or the backlog is thin it maybe worth growing into adjacent spaces but for now the point made about being more appropriate for the UI projects on the ecosystem seems one that apt. But I'm no a maintainer and just my thought as someone actively implementing MCP in the ecosystem.

@24601 commented on GitHub (Dec 1, 2024): @erodactyl definitely a bit of a scope question, I think maintainers and stakeholders probably have to ask themselves the question of scope independent of MCP. As it stands now Ollama can be used with the MCP OpenAI server by pointing it to the Ollama endpoint and as for host, I would think if the core feature work is done or the backlog is thin it maybe worth growing into adjacent spaces but for now the point made about being more appropriate for the UI projects on the ecosystem seems one that apt. But I'm no a maintainer and just my thought as someone actively implementing MCP in the ecosystem.

GiteaMirror commented

2026-04-22 10:42:32 -05:00

@andrewssobral commented on GitHub (Dec 1, 2024):

@erodactyl @24601 @ryana @itsPreto @ParthSareen

In my opinion, the ideal approach would be to implement the MCP host directly in Ollama. This is because we need to consider enterprise solutions that communicate directly with Ollama for privacy reasons.

I also don’t think it’s a good idea to “delegate” the integration with MCP to external applications (e.g., user interfaces like open-webui) because not all “users” of Ollama are people. Many are integrated systems that can communicate directly with Ollama using the Ollama Python SDK.

I’m also extremely excited to see this feature implemented natively in Ollama because I believe it will open up many possibilities, especially for those who prioritize privacy and are looking to develop automated solutions.

@andrewssobral commented on GitHub (Dec 1, 2024): @erodactyl @24601 @ryana @itsPreto @ParthSareen In my opinion, the ideal approach would be to implement the MCP host directly in Ollama. This is because we need to consider enterprise solutions that communicate directly with Ollama for privacy reasons. I also don’t think it’s a good idea to “delegate” the integration with MCP to external applications (e.g., user interfaces like open-webui) because not all “users” of Ollama are people. Many are integrated systems that can communicate directly with Ollama using the Ollama Python SDK. I’m also extremely excited to see this feature implemented natively in Ollama because I believe it will open up many possibilities, especially for those who prioritize privacy and are looking to develop automated solutions.

GiteaMirror commented

2026-04-22 10:42:32 -05:00

@24601 commented on GitHub (Dec 2, 2024):

@erodactyl @24601 @ryana @itsPreto @ParthSareen

In my opinion, the ideal approach would be to implement the MCP host directly in Ollama. This is because we need to consider enterprise solutions that communicate directly with Ollama for privacy reasons.

I also don’t think it’s a good idea to “delegate” the integration with MCP to external applications (e.g., user interfaces like open-webui) because not all “users” of Ollama are people. Many are integrated systems that can communicate directly with Ollama using the Ollama Python SDK.

I’m also extremely excited to see this feature implemented natively in Ollama because I believe it will open up many possibilities, especially for those who prioritize privacy and are looking to develop automated solutions.

@andrewssobral - I am genuinely (not rhetorically) asking the following questions, as I really think MCP is great and I may very well just be missing or failing to grasp your vision for what you're suggesting, so please know that/read it with that genuine curiosity and non-oppositional stance:

What would that look like? MCP has a many modes of operations? Are you suggesting, for example, the CLI for Ollama function as an MCP Host? Are you suggesting that Ollama maintain an official MCP Server that allows other LLMs to call Ollama APIs (in which case I wonder why the extant OpenAI API Server wouldn't suffice).

Again, I am just a rando in the ecosystem intersection of Ollama and MCP implementing MCP, so I really do see the value what MCP is doing is quite great/large and should be taken seriously, I just have not quite seen/heard a concrete use case or implementation for MCP in-tree to Ollama yet, which doesn't mean there isn't one, but what are you thinking, specifically? So far, "support MCP" is pretty much all I've seen/heard, which is kind of like "let's go somewhere!", which, well, yes, I'm all for adventure, but where makes a huge difference, and I just want to know/hear what your ideas are specifically, because MCP has many interesting uses, and I would be very interested to hear where you think MCP overlaps with core in-tree Ollama feature/function and scope of the project.

@24601 commented on GitHub (Dec 2, 2024): > @erodactyl @24601 @ryana @itsPreto @ParthSareen > > > > In my opinion, the ideal approach would be to implement the MCP host directly in Ollama. This is because we need to consider enterprise solutions that communicate directly with Ollama for privacy reasons. > > > > I also don’t think it’s a good idea to “delegate” the integration with MCP to external applications (e.g., user interfaces like open-webui) because not all “users” of Ollama are people. Many are integrated systems that can communicate directly with Ollama using the Ollama Python SDK. > > > > I’m also extremely excited to see this feature implemented natively in Ollama because I believe it will open up many possibilities, especially for those who prioritize privacy and are looking to develop automated solutions. @andrewssobral - I am genuinely (not rhetorically) asking the following questions, as I really think MCP is great and I may very well just be missing or failing to grasp your vision for what you're suggesting, so please know that/read it with that genuine curiosity and non-oppositional stance: What would that look like? MCP has a many modes of operations? Are you suggesting, for example, the CLI for Ollama function as an MCP Host? Are you suggesting that Ollama maintain an official MCP Server that allows other LLMs to call Ollama APIs (in which case I wonder why the extant OpenAI API Server wouldn't suffice). Again, I am just a rando in the ecosystem intersection of Ollama and MCP implementing MCP, so I really do see the value what MCP is doing is quite great/large and should be taken seriously, I just have not quite seen/heard a concrete use case or implementation for MCP in-tree to Ollama yet, which doesn't mean there isn't one, but what are you thinking, specifically? So far, "support MCP" is pretty much all I've seen/heard, which is kind of like "let's go somewhere!", which, well, yes, I'm all for adventure, but _where_ makes a huge difference, and I just want to know/hear what your ideas are specifically, because MCP has many interesting uses, and I would be very interested to hear where you think MCP overlaps with core in-tree Ollama feature/function and scope of the project.

GiteaMirror commented

2026-04-22 10:42:33 -05:00

@andrewssobral commented on GitHub (Dec 2, 2024):

@erodactyl @24601 @ryana @itsPreto @ParthSareen
In my opinion, the ideal approach would be to implement the MCP host directly in Ollama. This is because we need to consider enterprise solutions that communicate directly with Ollama for privacy reasons.
I also don’t think it’s a good idea to “delegate” the integration with MCP to external applications (e.g., user interfaces like open-webui) because not all “users” of Ollama are people. Many are integrated systems that can communicate directly with Ollama using the Ollama Python SDK.
I’m also extremely excited to see this feature implemented natively in Ollama because I believe it will open up many possibilities, especially for those who prioritize privacy and are looking to develop automated solutions.

@andrewssobral - I am genuinely (not rhetorically) asking the following questions, as I really think MCP is great and I may very well just be missing or failing to grasp your vision for what you're suggesting, so please know that/read it with that genuine curiosity and non-oppositional stance:

What would that look like? MCP has a many modes of operations? Are you suggesting, for example, the CLI for Ollama function as an MCP Host? Are you suggesting that Ollama maintain an official MCP Server that allows other LLMs to call Ollama APIs (in which case I wonder why the extant OpenAI API Server wouldn't suffice).

Again, I am just a rando in the ecosystem intersection of Ollama and MCP implementing MCP, so I really do see the value what MCP is doing is quite great/large and should be taken seriously, I just have not quite seen/heard a concrete use case or implementation for MCP in-tree to Ollama yet, which doesn't mean there isn't one, but what are you thinking, specifically? So far, "support MCP" is pretty much all I've seen/heard, which is kind of like "let's go somewhere!", which, well, yes, I'm all for adventure, but where makes a huge difference, and I just want to know/hear what your ideas are specifically, because MCP has many interesting uses, and I would be very interested to hear where you think MCP overlaps with core in-tree Ollama feature/function and scope of the project.

@24601 I believe the ideal approach would be for the Ollama CLI to function as an MCP Host, so that when a user makes a request in an external tool (e.g., “search for this on the web”), Ollama can initiate communication with the appropriate tool. To enable this, users should be able to register which MCP Servers they want to use, similar to how it is done with Claude Desktop.

@andrewssobral commented on GitHub (Dec 2, 2024): > > @erodactyl @24601 @ryana @itsPreto @ParthSareen > > In my opinion, the ideal approach would be to implement the MCP host directly in Ollama. This is because we need to consider enterprise solutions that communicate directly with Ollama for privacy reasons. > > I also don’t think it’s a good idea to “delegate” the integration with MCP to external applications (e.g., user interfaces like open-webui) because not all “users” of Ollama are people. Many are integrated systems that can communicate directly with Ollama using the Ollama Python SDK. > > I’m also extremely excited to see this feature implemented natively in Ollama because I believe it will open up many possibilities, especially for those who prioritize privacy and are looking to develop automated solutions. > > @andrewssobral - I am genuinely (not rhetorically) asking the following questions, as I really think MCP is great and I may very well just be missing or failing to grasp your vision for what you're suggesting, so please know that/read it with that genuine curiosity and non-oppositional stance: > > What would that look like? MCP has a many modes of operations? Are you suggesting, for example, the CLI for Ollama function as an MCP Host? Are you suggesting that Ollama maintain an official MCP Server that allows other LLMs to call Ollama APIs (in which case I wonder why the extant OpenAI API Server wouldn't suffice). > > Again, I am just a rando in the ecosystem intersection of Ollama and MCP implementing MCP, so I really do see the value what MCP is doing is quite great/large and should be taken seriously, I just have not quite seen/heard a concrete use case or implementation for MCP in-tree to Ollama yet, which doesn't mean there isn't one, but what are you thinking, specifically? So far, "support MCP" is pretty much all I've seen/heard, which is kind of like "let's go somewhere!", which, well, yes, I'm all for adventure, but _where_ makes a huge difference, and I just want to know/hear what your ideas are specifically, because MCP has many interesting uses, and I would be very interested to hear where you think MCP overlaps with core in-tree Ollama feature/function and scope of the project. @24601 I believe the ideal approach would be for the Ollama CLI to function as an MCP Host, so that when a user makes a request in an external tool (e.g., “search for this on the web”), Ollama can initiate communication with the appropriate tool. To enable this, users should be able to register which MCP Servers they want to use, similar to how it is done with Claude Desktop.

GiteaMirror commented

2026-04-22 10:42:34 -05:00

@erodactyl commented on GitHub (Dec 2, 2024):

@erodactyl @24601 @ryana @itsPreto @ParthSareen
In my opinion, the ideal approach would be to implement the MCP host directly in Ollama. This is because we need to consider enterprise solutions that communicate directly with Ollama for privacy reasons.
I also don’t think it’s a good idea to “delegate” the integration with MCP to external applications (e.g., user interfaces like open-webui) because not all “users” of Ollama are people. Many are integrated systems that can communicate directly with Ollama using the Ollama Python SDK.
I’m also extremely excited to see this feature implemented natively in Ollama because I believe it will open up many possibilities, especially for those who prioritize privacy and are looking to develop automated solutions.

@andrewssobral - I am genuinely (not rhetorically) asking the following questions, as I really think MCP is great and I may very well just be missing or failing to grasp your vision for what you're suggesting, so please know that/read it with that genuine curiosity and non-oppositional stance:

What would that look like? MCP has a many modes of operations? Are you suggesting, for example, the CLI for Ollama function as an MCP Host? Are you suggesting that Ollama maintain an official MCP Server that allows other LLMs to call Ollama APIs (in which case I wonder why the extant OpenAI API Server wouldn't suffice).

Again, I am just a rando in the ecosystem intersection of Ollama and MCP implementing MCP, so I really do see the value what MCP is doing is quite great/large and should be taken seriously, I just have not quite seen/heard a concrete use case or implementation for MCP in-tree to Ollama yet, which doesn't mean there isn't one, but what are you thinking, specifically? So far, "support MCP" is pretty much all I've seen/heard, which is kind of like "let's go somewhere!", which, well, yes, I'm all for adventure, but where makes a huge difference, and I just want to know/hear what your ideas are specifically, because MCP has many interesting uses, and I would be very interested to hear where you think MCP overlaps with core in-tree Ollama feature/function and scope of the project.

I fully agree with @andrewssobral, I think you are looking at this in reverse. We don't want other AI tools to call Ollama as an MCP server. We want Ollama to be the MCP host / client similar to Claude Desktop. It will READ external data sources, nor PROVIDE the data to other MCP clients.

Where do we want to go?

We want to give standardized access to external tool reading to people / companies who use Ollama. They will be able to use any MCP server out of the box. We already have many MCP servers like filesystem, Postgresql, Google Maps and you can find many others in this repo. All of this, and many more data source integrations that will become available over time, will be available to use directly with Ollama. This will provide huge value for local LLMs.

@erodactyl commented on GitHub (Dec 2, 2024): > > @erodactyl @24601 @ryana @itsPreto @ParthSareen > > In my opinion, the ideal approach would be to implement the MCP host directly in Ollama. This is because we need to consider enterprise solutions that communicate directly with Ollama for privacy reasons. > > I also don’t think it’s a good idea to “delegate” the integration with MCP to external applications (e.g., user interfaces like open-webui) because not all “users” of Ollama are people. Many are integrated systems that can communicate directly with Ollama using the Ollama Python SDK. > > I’m also extremely excited to see this feature implemented natively in Ollama because I believe it will open up many possibilities, especially for those who prioritize privacy and are looking to develop automated solutions. > > @andrewssobral - I am genuinely (not rhetorically) asking the following questions, as I really think MCP is great and I may very well just be missing or failing to grasp your vision for what you're suggesting, so please know that/read it with that genuine curiosity and non-oppositional stance: > > What would that look like? MCP has a many modes of operations? Are you suggesting, for example, the CLI for Ollama function as an MCP Host? Are you suggesting that Ollama maintain an official MCP Server that allows other LLMs to call Ollama APIs (in which case I wonder why the extant OpenAI API Server wouldn't suffice). > > Again, I am just a rando in the ecosystem intersection of Ollama and MCP implementing MCP, so I really do see the value what MCP is doing is quite great/large and should be taken seriously, I just have not quite seen/heard a concrete use case or implementation for MCP in-tree to Ollama yet, which doesn't mean there isn't one, but what are you thinking, specifically? So far, "support MCP" is pretty much all I've seen/heard, which is kind of like "let's go somewhere!", which, well, yes, I'm all for adventure, but _where_ makes a huge difference, and I just want to know/hear what your ideas are specifically, because MCP has many interesting uses, and I would be very interested to hear where you think MCP overlaps with core in-tree Ollama feature/function and scope of the project. I fully agree with @andrewssobral, I think you are looking at this in reverse. We don't want other AI tools to call Ollama as an MCP server. We want Ollama to be the MCP host / client similar to Claude Desktop. It will READ external data sources, nor PROVIDE the data to other MCP clients. > Where do we want to go? We want to give standardized access to external tool reading to people / companies who use Ollama. They will be able to use any MCP server out of the box. We already have many MCP servers like [filesystem](https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem), [Postgresql](https://github.com/modelcontextprotocol/servers/tree/main/src/postgres), [Google Maps](https://github.com/modelcontextprotocol/servers/tree/main/src/google-maps) and you can find many others in this [repo](https://github.com/modelcontextprotocol/servers?tab=readme-ov-file). All of this, and many more data source integrations that will become available over time, will be available to use directly with Ollama. This will provide huge value for local LLMs.

GiteaMirror commented

2026-04-22 10:42:34 -05:00

@24601 commented on GitHub (Dec 2, 2024):

Fair enough @andrewssobral and @erodactyl - those seem like nice use cases, and leads me to wonder about a couple (again, not leading or rhetorical, but genuine) questions:

What is the current the value prop of Ollama? What are the current use case(s)?
What should be (aspirationally) value prop of Ollama? What should be the use case?

I am not overly familiar with Ollama's governance model and maybe very well be if a PR for such a feature/function tickles a maintainer's fancy it ends up in-tree (the beauty of OSS!), so there may just not be this level of formalism or study here, but I genuinely wonder how people use Ollama and how that maybe shifting.

Personally (and in the circles I work in), which I hardly will assume is or should be representative of the broad and diverse Ollama community, I see the Ollama CLI as a "smoke test" and Ollama almost always is accessed as an API by one of the many apps in "Community Integrations" in the README.md, etc. In that sense/use case, Ollama is an inference engine at its core, bringing the ability to pull/package models and run them on diverse hardware behind a relatively easy to use/build/deliver toolset/library/API. In that use case (again, I know hardly the only one nor even one I will claim is or is not dominant/primary/core, that's not a discussion for me and one I'll leave to the maintainers/governance process stakeholders), the embodiment of MCP I would find most useful would actually be substantially different than packaging Ollama as an "MCP Host" to compete/function with OpenWebUI/Claude Desktop/etc (a steep and unnecessary hill that seems to be a side journey IMO), I think an Ollama MCP server would be one that would allow other LLMs to discover (via search) and pull/bring up for inference a broad gamut of models on a given machine (e.g. imagine Ollama providing Claude the ability to search and pull the full spectrum of models to then, once the download is complete, begin to make calls against!). This is far more 1) unique 2) central to what at least I perceive to be the unique and meaningful value proposition of Ollama in the ecosystem 3) differentiated and valuable to the user/ecosystem 4) non-competitive/distractive from the core work.

Of course, "the best at everything" is something that is very appealing, but before any MCP-fun at the Ollama layer as a host, I think Ollama could benefit much more from moving things forward that are in the core-inference-engine-scope like:

Speculative Decoding
Audio to Audio
OpenCL
Realtime Voice

Again, don't mean to sound like a downer or against any of this, just an interesting conversation with others who see the value of MCP and are users of Ollama that I think we can learn from each other in how we use Ollama and what we value and the future direction of the value of Ollama as it grows!

@24601 commented on GitHub (Dec 2, 2024): Fair enough @andrewssobral and @erodactyl - those seem like nice use cases, and leads me to wonder about a couple (again, not leading or rhetorical, but genuine) questions: 1. What is the current the value prop of Ollama? What are the current use case(s)? 2. What should be (aspirationally) value prop of Ollama? What should be the use case? I am not overly familiar with Ollama's governance model and maybe very well be if a PR for such a feature/function tickles a maintainer's fancy it ends up in-tree (the beauty of OSS!), so there may just not be this level of formalism or study here, but I genuinely wonder how people use Ollama and how that maybe shifting. Personally (and in the circles I work in), which I hardly will assume is or should be representative of the broad and diverse Ollama community, I see the Ollama CLI as a "smoke test" and Ollama almost always is accessed as an API by one of the many apps in "Community Integrations" in the README.md, etc. In that sense/use case, Ollama is an inference engine at its core, bringing the ability to pull/package models and run them on diverse hardware behind a relatively easy to use/build/deliver toolset/library/API. In that use case (again, I know hardly the only one nor even one I will claim is or is not dominant/primary/core, that's not a discussion for me and one I'll leave to the maintainers/governance process stakeholders), the embodiment of MCP I would find most useful would actually be substantially different than packaging Ollama as an "MCP Host" to compete/function with OpenWebUI/Claude Desktop/etc (a steep and unnecessary hill that seems to be a side journey IMO), I think an Ollama MCP server would be one that would allow other LLMs to discover (via search) and pull/bring up for inference a broad gamut of models on a given machine (e.g. imagine Ollama providing Claude the ability to search and pull the full spectrum of models to then, once the download is complete, begin to make calls against!). This is far more 1) unique 2) central to what at least I perceive to be the unique and meaningful value proposition of Ollama in the ecosystem 3) differentiated and valuable to the user/ecosystem 4) non-competitive/distractive from the core work. Of course, "the best at everything" is something that is very appealing, but before any MCP-fun at the Ollama layer as a host, I think Ollama could benefit much more from moving things forward that are in the core-inference-engine-scope like: 1. Speculative Decoding 2. Audio to Audio 3. OpenCL 4. Realtime Voice Again, don't mean to sound like a downer or against any of this, just an interesting conversation with others who see the value of MCP and are users of Ollama that I think we can learn from each other in how we use Ollama and what we value and the future direction of the value of Ollama as it grows!

GiteaMirror commented

2026-04-22 10:42:35 -05:00

@dsp-ant commented on GitHub (Dec 2, 2024):

Hey,

I got a link to this conversation. I am one of the MCP core team members. We'd love to see Ollama and the larger Ollama ecosystem adopt MCP in the way the community feels best suited for Ollama. After all, we want this to be an open protocol with involvement from wider open source community. We are happy to answer any questions or discuss any problems/feedback, etc you have on MCP.

@dsp-ant commented on GitHub (Dec 2, 2024): Hey, I got a link to this conversation. I am one of the MCP core team members. We'd love to see Ollama and the larger Ollama ecosystem adopt MCP in the way the community feels best suited for Ollama. After all, we want this to be an open protocol with involvement from wider open source community. We are happy to answer any questions or discuss any problems/feedback, etc you have on MCP.

GiteaMirror commented

2026-04-22 10:42:35 -05:00

@andrewssobral commented on GitHub (Dec 2, 2024):

@24601 I see that you view the idea of MCP in the opposite direction from what we are envisioning in this post. Imagining Ollama offering Claude the ability to search and bring the full spectrum of models wouldn’t solve the privacy problem. Additionally, there are already MCP servers that allow, for instance, Claude Desktop to query models from OpenAI and others, and these even seem to support Ollama (see mcp-server-openai and unichat-mcp-server). In summary, this isn’t the direction we’re considering.

Moreover, @dsp-ant , correct me if I’m wrong, making Ollama natively an MCP Host can be seen as an extension of the Function Calling/Tools concept (which Ollama already supports). The advantage of using MCP servers compared to the current Function Calling/Tools support is that we can leverage the entire ecosystem being built around MCP technology instead of requiring users to implement Function Calling/Tools manually every time they need Ollama to communicate with a third-party tool.

Keep in mind that integrating Ollama with MCP Server support is a significant step for enterprise solutions that need automation with privacy. A major plus of MCP is its focus on privacy, where MCP Servers run locally and are responsible for accessing private data, ensuring that OpenAI’s and Claude’s LLMs don’t have direct access to sensitive information. Furthermore, an MCP server alone solves only part of the problem. Even if MCP servers isolate data access, the data itself still flows to OpenAI or Claude LLMs, which many companies aim to avoid. To ensure a complete privacy pipeline, Ollama needs to act as an MCP Host and communicate with MCP servers, guaranteeing that all data communication happens internally without data leakage.

When I referred to the Ollama CLI, I meant the core of Ollama, because, as you said, not everyone uses the CLI (via command prompt or terminal) but instead uses the Ollama Python SDK to integrate with other third-party tools. Naturally, having MCP support both in the CLI and via its API (Python SDK) is crucial to enable integration and automation with third-party software.

@andrewssobral commented on GitHub (Dec 2, 2024): @24601 I see that you view the idea of MCP in the opposite direction from what we are envisioning in this post. Imagining Ollama offering Claude the ability to search and bring the full spectrum of models wouldn’t solve the privacy problem. Additionally, there are already MCP servers that allow, for instance, Claude Desktop to query models from OpenAI and others, and these even seem to support Ollama (see [mcp-server-openai](https://github.com/pierrebrunelle/mcp-server-openai) and [unichat-mcp-server](https://github.com/amidabuddha/unichat-mcp-server)). In summary, this isn’t the direction we’re considering. Moreover, @dsp-ant , correct me if I’m wrong, making Ollama natively an MCP Host can be seen as an extension of the Function Calling/Tools concept (which Ollama already supports). The advantage of using MCP servers compared to the current Function Calling/Tools support is that we can leverage the entire ecosystem being built around MCP technology instead of requiring users to implement Function Calling/Tools manually every time they need Ollama to communicate with a third-party tool. Keep in mind that integrating Ollama with MCP Server support is a significant step for enterprise solutions that need automation with privacy. A major plus of MCP is its focus on privacy, where MCP Servers run locally and are responsible for accessing private data, ensuring that OpenAI’s and Claude’s LLMs don’t have direct access to sensitive information. Furthermore, an MCP server alone solves only part of the problem. Even if MCP servers isolate data access, the data itself still flows to OpenAI or Claude LLMs, which many companies aim to avoid. To ensure a complete privacy pipeline, Ollama needs to act as an MCP Host and communicate with MCP servers, guaranteeing that all data communication happens internally without data leakage. When I referred to the Ollama CLI, I meant the core of Ollama, because, as you said, not everyone uses the CLI (via command prompt or terminal) but instead uses the Ollama Python SDK to integrate with other third-party tools. Naturally, having MCP support both in the CLI and via its API (Python SDK) is crucial to enable integration and automation with third-party software.

GiteaMirror commented

2026-04-22 10:42:37 -05:00

@bartolli commented on GitHub (Dec 3, 2024):

MCP-LLM Bridge

I created a bridge for using MCP tools with Ollama and other OpenAI-compatible endpoints. The bridge translates between MCP's tool interface and OpenAI's function calling spec.

While I originally built it to work with OpenAI's API, it also works great with Ollama, LM Studio, or any endpoint that implements the OpenAI API spec.

The code is up on GitHub here. Feel free to check it out and let me know what you think!

@bartolli commented on GitHub (Dec 3, 2024): # MCP-LLM Bridge I created a bridge for using MCP tools with Ollama and other OpenAI-compatible endpoints. The bridge translates between MCP's tool interface and OpenAI's function calling spec. While I originally built it to work with OpenAI's API, it also works great with Ollama, LM Studio, or any endpoint that implements the OpenAI API spec. The code is up on GitHub [here](https://github.com/bartolli/mcp-llm-bridge). Feel free to check it out and let me know what you think!

GiteaMirror commented

2026-04-22 10:42:37 -05:00

@dsp-ant commented on GitHub (Dec 3, 2024):

Moreover, @dsp-ant , correct me if I’m wrong, making Ollama natively an MCP Host can be seen as an extension of the Function Calling/Tools concept (which Ollama already supports). The advantage of using MCP servers compared to the current Function Calling/Tools support is that we can leverage the entire ecosystem being built around MCP technology instead of requiring users to implement Function Calling/Tools manually every time they need Ollama to communicate with a third-party tool.

To some degree this is true. Note that MCP supports more than just tools. Resources and Prompts (which effectively are just templates) are also part of the specification. For a CLI runtime such as Ollama, focusing purely on tool integration might be useful as an abstraction to use the wider ecosystem and to make it fairly trivial for people to add tools in any programming language they feel most comfortable. IF ollama implements MCP as a host, I would suggest to also support Sampling, such that an MCP server can ask Ollama for completions, effectively enabling little standalone agents of arbitrary complexity.

Resources and Prompts are likely most useful to applications (particular UIs) wrapping ollama that do additonal logic. Prompts are meant as user driven additions, (.e.g zed implements these as slash commands e.g. /pg-schema <table> will give you a schema of a database table from the postgres mcp server). Resources are meant as file-like objects that the application itself can decide how to use (this is most useful for applications who do additional context selection, etc).

Hope that helps

@dsp-ant commented on GitHub (Dec 3, 2024): > Moreover, @dsp-ant , correct me if I’m wrong, making Ollama natively an MCP Host can be seen as an extension of the Function Calling/Tools concept (which Ollama already supports). The advantage of using MCP servers compared to the current Function Calling/Tools support is that we can leverage the entire ecosystem being built around MCP technology instead of requiring users to implement Function Calling/Tools manually every time they need Ollama to communicate with a third-party tool. To some degree this is true. Note that MCP supports more than just tools. Resources and Prompts (which effectively are just templates) are also part of the specification. For a CLI runtime such as Ollama, focusing purely on tool integration might be useful as an abstraction to use the wider ecosystem and to make it fairly trivial for people to add tools in any programming language they feel most comfortable. IF ollama implements MCP as a host, I would suggest to also support Sampling, such that an MCP server can ask Ollama for completions, effectively enabling little standalone agents of arbitrary complexity. Resources and Prompts are likely most useful to applications (particular UIs) wrapping ollama that do additonal logic. Prompts are meant as user driven additions, (.e.g zed implements these as slash commands e.g. `/pg-schema <table>` will give you a schema of a database table from the postgres mcp server). Resources are meant as file-like objects that the application itself can decide how to use (this is most useful for applications who do additional context selection, etc). Hope that helps

GiteaMirror commented

2026-04-22 10:42:38 -05:00

@sammcj commented on GitHub (Dec 5, 2024):

Here's a gross hack up I did of an Ollama MCP bridge the other day, absolutely do not use it for anything other than toying with - https://github.com/sammcj/gomcp

@sammcj commented on GitHub (Dec 5, 2024): Here's a gross hack up I did of an Ollama MCP bridge the other day, absolutely do not use it for anything other than toying with - https://github.com/sammcj/gomcp

GiteaMirror commented

2026-04-22 10:42:38 -05:00

@24601 commented on GitHub (Dec 5, 2024):

@24601 I see that you view the idea of MCP in the opposite direction from what we are envisioning in this post. Imagining Ollama offering Claude the ability to search and bring the full spectrum of models wouldn’t solve the privacy problem. Additionally, there are already MCP servers that allow, for instance, Claude Desktop to query models from OpenAI and others, and these even seem to support Ollama (see mcp-server-openai and unichat-mcp-server). In summary, this isn’t the direction we’re considering.

You certainly aren't wrong, I am just curious what level of end-user application functionality lives in-tree and what does not and where that line is now and how it may/should evolve. Seems like @dsp-ant does draw out a very good distinction between the various use cases and feature functions that seems reasonable.

@24601 commented on GitHub (Dec 5, 2024): > @24601 I see that you view the idea of MCP in the opposite direction from what we are envisioning in this post. Imagining Ollama offering Claude the ability to search and bring the full spectrum of models wouldn’t solve the privacy problem. Additionally, there are already MCP servers that allow, for instance, Claude Desktop to query models from OpenAI and others, and these even seem to support Ollama (see [mcp-server-openai](https://github.com/pierrebrunelle/mcp-server-openai) and [unichat-mcp-server](https://github.com/amidabuddha/unichat-mcp-server)). In summary, this isn’t the direction we’re considering. > You certainly aren't wrong, I am just curious what level of end-user application functionality lives in-tree and what does not and where that line is now and how it may/should evolve. Seems like @dsp-ant does draw out a very good distinction between the various use cases and feature functions that seems reasonable.

GiteaMirror commented

2026-04-22 10:42:39 -05:00

@josx commented on GitHub (Dec 5, 2024):

Here a cli to use with ollama https://github.com/chrishayuk/mcp-cli

@josx commented on GitHub (Dec 5, 2024): Here a cli to use with ollama https://github.com/chrishayuk/mcp-cli

GiteaMirror commented

2026-04-22 10:42:40 -05:00

@nixoid commented on GitHub (Dec 10, 2024):

cli is a good start but server-side implementation is def. necessary for mobile devices and other clients

@nixoid commented on GitHub (Dec 10, 2024): cli is a good start but server-side implementation is def. necessary for mobile devices and other clients

GiteaMirror commented

2026-04-22 10:42:40 -05:00

@josx commented on GitHub (Dec 23, 2024):

Question:
Is there any way to use any of the above bridges and but not using their cli intefaces? maybe as proxy for API calls?
I want to integrate openwebui as interface that I have already configured with ollama as inference.

@josx commented on GitHub (Dec 23, 2024): Question: Is there any way to use any of the above bridges and but not using their cli intefaces? maybe as proxy for API calls? I want to integrate openwebui as interface that I have already configured with ollama as inference.

GiteaMirror commented

2026-04-22 10:42:41 -05:00

@yuyangchee98 commented on GitHub (Dec 23, 2024):

@josx this may be what you want https://github.com/SecretiveShell/MCP-Bridge

@yuyangchee98 commented on GitHub (Dec 23, 2024): @josx this may be what you want https://github.com/SecretiveShell/MCP-Bridge

GiteaMirror commented

2026-04-22 10:42:41 -05:00

@ggozad commented on GitHub (Jan 15, 2025):

Hey,
I am the author of oterm a terminal client for Ollama. I was told about this discussion and found it super intriguing.
I spent some time to bridge MCP tools to Ollama tools in order to be used with oterm. This will need some polishing but it opens so many possibilities!

You can follow progress here, and see a screenshot of using the "git_status" tool from the git MCP server in oterm 😎

I will try to merge and release as soon as I test a bit more and document properly.

@ggozad commented on GitHub (Jan 15, 2025): Hey, I am the author of [oterm](https://github.com/ggozad/oterm) a terminal client for Ollama. I was told about this discussion and found it super intriguing. I spent some time to bridge MCP tools to Ollama tools in order to be used with oterm. This will need some polishing but it opens so many possibilities! You can follow progress [here](https://github.com/ggozad/oterm/pull/155), and see a screenshot of using the "git_status" tool from the git MCP server in oterm 😎 I will try to merge and release as soon as I test a bit more and document properly.

GiteaMirror commented

2026-04-22 10:42:42 -05:00

@ggozad commented on GitHub (Jan 20, 2025):

oterm 0.8.0 will now connect to MCP servers and convert MCP tools to Ollama tools for use with tool-supporting models.

@ggozad commented on GitHub (Jan 20, 2025): [oterm](https://github.com/ggozad/oterm) 0.8.0 will now connect to MCP servers and convert MCP tools to Ollama tools for use with tool-supporting models.

GiteaMirror commented

2026-04-22 10:42:43 -05:00

@defaultsecurity commented on GitHub (Mar 6, 2025):

Yes, please +1!

@defaultsecurity commented on GitHub (Mar 6, 2025): Yes, please +1!

GiteaMirror commented

2026-04-22 10:42:43 -05:00

@diiyw commented on GitHub (Mar 17, 2025):

Yes, please +1!

@diiyw commented on GitHub (Mar 17, 2025): Yes, please +1!

GiteaMirror commented

2026-04-22 10:42:44 -05:00

@TeamDman commented on GitHub (Mar 23, 2025):

I've only briefly explored MCP stuff, but my understanding is it's basically an abstraction over tool-calling that adds an approval stage for tool use? This seems like something not impossible to do well as a helper library/program, rather than something that can only be done well by upstreaming it.

I love Ollama, and I know that developer time is a limited resource.
To add my voice, this feature isn't a priority for me and I hope Ollama contributors are happy spending their time as they see fit.

If only there was some way that I could use language to communicate with the computer to figure out how hard it could possibly be to implement this myself, if it were such a pressing need for me.....

@TeamDman commented on GitHub (Mar 23, 2025): I've only briefly explored MCP stuff, but my understanding is it's basically an abstraction over tool-calling that adds an approval stage for tool use? This seems like something not impossible to do well as a helper library/program, rather than something that can only be done well by upstreaming it. I love Ollama, and I know that developer time is a limited resource. To add my voice, this feature isn't a priority for me and I hope Ollama contributors are happy spending their time as they see fit. If only there was some way that _I could use language to communicate with the computer_ to figure out how hard it could possibly be to implement this myself, if it were such a pressing need for me.....

GiteaMirror commented

2026-04-22 10:42:45 -05:00

@ggozad commented on GitHub (Mar 23, 2025):

So I have spent quite some time looking at MCP from the perspective of implementing what makes sense in terms of my Ollama client oterm. I have already implemented a Tool bridge and plan to also support Prompts, Sampling and Resource. I find the idea great and super useful but I am not so sure how Ollama would fit in or if it needs to. Here are some thoughts:

Tools: that's a no brainer. Ollama already has tool support. It could definitely improve (and there are a number of issues open for that, unreleated to MCP) but all that is needed is a bridge and there are already some libraries out that can be used. This is atm well handled by clients that just do that, fetch MCP tools and convert and feed them to Ollama.
Resources: this seems irrelevant to me from the perspective of Ollama. It's a feature best handled by clients who can use them to provide context to LLMs.
Prompts: again a feature to be consumed by client. The MCP server constructs a list of messages that the client can feed to Ollama.
Sampling: now this is kind of interesting. Ollama could use this to give direct access to completions on demand using its hosted models. There is a significant amount of work to do this and I haven't seen other implementations. I am planning to do it (again as a bridge to Ollama) with oterm but it's not a priority.
Roots: a client feature. Can't see how Ollama would use this.

Do I miss something here?

@ggozad commented on GitHub (Mar 23, 2025): So I have spent quite some time looking at MCP from the perspective of implementing what makes sense in terms of my Ollama client [oterm](https://github.com/ggozad/oterm). I have already implemented a `Tool` bridge and plan to also support `Prompts`, `Sampling` and `Resource`. I find the idea great and super useful but I am not so sure how Ollama would fit in or if it needs to. Here are some thoughts: - `Tools`: that's a no brainer. Ollama already has tool support. It could definitely improve (and there are a number of issues open for that, unreleated to MCP) but all that is needed is a bridge and there are already some libraries out that can be used. This is atm well handled by clients that just do that, fetch MCP tools and convert and feed them to Ollama. - `Resources`: this seems irrelevant to me from the perspective of Ollama. It's a feature best handled by clients who can use them to provide context to LLMs. - `Prompts`: again a feature to be consumed by client. The MCP server constructs a list of messages that the client can feed to Ollama. - `Sampling`: now this is kind of interesting. Ollama could use this to give direct access to completions on demand using its hosted models. There is a significant amount of work to do this and I haven't seen other implementations. I am planning to do it (again as a bridge to Ollama) with `oterm` but it's not a priority. - `Roots`: a client feature. Can't see how Ollama would use this. Do I miss something here?

GiteaMirror commented

2026-04-22 10:42:45 -05:00

@lemassykoi commented on GitHub (Mar 23, 2025):

Resources: this seems irrelevant to me from the perspective of Ollama. It's a feature best handled by clients who can use them to provide context to LLMs.

I would have thought to use Resources as "tool without input"

@lemassykoi commented on GitHub (Mar 23, 2025): > * `Resources`: this seems irrelevant to me from the perspective of Ollama. It's a feature best handled by clients who can use them to provide context to LLMs. ![Image](https://github.com/user-attachments/assets/dd00dc23-901f-46f1-b8fc-a0cef927aada) I would have thought to use Resources as "tool without input"

GiteaMirror commented

2026-04-22 10:42:46 -05:00

@ggozad commented on GitHub (Mar 23, 2025):

I would have thought to use Resources as "tool without input"

Resources can have input (the dynamic ones), which of course would mean "tool with input".
They also support "Updates".
I think the intention (which is admittedly vague) is that they are meant to be consumed from clients to serve context.

@ggozad commented on GitHub (Mar 23, 2025): > > I would have thought to use Resources as "tool without input" Resources *can* have input (the dynamic ones), which of course would mean "tool with input". They also support "Updates". I *think* the intention (which is admittedly vague) is that they are meant to be consumed from clients to serve context.

GiteaMirror commented

2026-04-22 10:42:47 -05:00

@pavleb commented on GitHub (Mar 25, 2025):

@ggozad Following your line of thought and description here: https://developers.redhat.com/blog/2025/01/22/quick-look-mcp-large-language-models-and-nodejs#, simple conversion between JSON of the MCP discovery makes this compatible with tools. In the link above check section Ollama. So following this, isn't tools enough or at least close enough?

@pavleb commented on GitHub (Mar 25, 2025): @ggozad Following your line of thought and description here: [https://developers.redhat.com/blog/2025/01/22/quick-look-mcp-large-language-models-and-nodejs#](https://developers.redhat.com/blog/2025/01/22/quick-look-mcp-large-language-models-and-nodejs#), simple conversion between JSON of the MCP discovery makes this compatible with tools. In the link above check section Ollama. So following this, isn't tools enough or at least close enough?

GiteaMirror commented

2026-04-22 10:42:48 -05:00

@ggozad commented on GitHub (Mar 25, 2025):

@ggozad Following your line of thought and description here: https://developers.redhat.com/blog/2025/01/22/quick-look-mcp-large-language-models-and-nodejs#, simple conversion between JSON of the MCP discovery makes this compatible with tools. In the link above check section Ollama. So following this, isn't tools enough or at least close enough?

Yeah, I think your implementation is straightforward and very similar to what I ended up doing in oterm.
Judging from what is out there, most MCP servers are just about Tools and the rest seems secondary. I just added support for Prompts in oterm and like I said plan to do more, but yes, Tools gets you to cover connecting to Ollama most MCP servers out there.

@ggozad commented on GitHub (Mar 25, 2025): > [@ggozad](https://github.com/ggozad) Following your line of thought and description here: https://developers.redhat.com/blog/2025/01/22/quick-look-mcp-large-language-models-and-nodejs#, simple conversion between JSON of the MCP discovery makes this compatible with tools. In the link above check section Ollama. So following this, isn't tools enough or at least close enough? Yeah, I think your implementation is straightforward and very similar to what I ended up doing in `oterm`. Judging from what is out there, most MCP servers are just about Tools and the rest seems secondary. I just added support for `Prompts` in oterm and like I said plan to do more, but yes, Tools gets you to cover connecting to Ollama most MCP servers out there.

GiteaMirror commented

2026-04-22 10:42:49 -05:00

@ParthSareen commented on GitHub (Mar 28, 2025):

Hi folks - just wanted to give you all a shout to say that we're keeping a close eye on this to see where we best fit into this story. You are heard and please continue putting down whatever thoughts you have on MCP, us, and how you would like to use Ollama with it (if you don't already do so). And yes improvements to tool calling and structured outputs are in the works to hopefully improve reliability! 🙏🏽 Thank you!

@ParthSareen commented on GitHub (Mar 28, 2025): Hi folks - just wanted to give you all a shout to say that we're keeping a close eye on this to see where we best fit into this story. You are heard and please continue putting down whatever thoughts you have on MCP, us, and how you would like to use Ollama with it (if you don't already do so). And yes improvements to tool calling and structured outputs are in the works to hopefully improve reliability! 🙏🏽 Thank you!

GiteaMirror commented

2026-04-22 10:42:50 -05:00

@moresearch commented on GitHub (Mar 29, 2025):

Thanks @ParthSareen

Here is a golang implementation that uses Ollama and had to do some extra parsing to convert from mcp-tools to ollama tools to make it work. If ollama supports with this out-of-the-box would be much more reliable.

https://k33g.hashnode.dev/building-a-generative-ai-mcp-client-application-in-go-using-ollama

@moresearch commented on GitHub (Mar 29, 2025): Thanks @ParthSareen Here is a golang implementation that uses Ollama and *had* to do some extra parsing to convert from mcp-tools to ollama tools to make it work. If ollama supports with this out-of-the-box would be much more reliable. https://k33g.hashnode.dev/building-a-generative-ai-mcp-client-application-in-go-using-ollama

GiteaMirror commented

2026-04-22 10:42:50 -05:00

@sheffler commented on GitHub (Apr 2, 2025):

See https://github.com/ollama/ollama/pull/10091 which helps Ollama handle tool argument types better. (Works great with oterm!)

@sheffler commented on GitHub (Apr 2, 2025): See https://github.com/ollama/ollama/pull/10091 which helps Ollama handle tool argument types better. (Works great with oterm!)

GiteaMirror commented

2026-04-22 10:42:51 -05:00

@ggozad commented on GitHub (Apr 13, 2025):

oterm now supports MCP Sampling 🎉

This basically allows connected MCP servers to request completions from Ollama-hosted LLMs.

@ggozad commented on GitHub (Apr 13, 2025): [oterm](https://github.com/ggozad/oterm) now supports [MCP Sampling](https://modelcontextprotocol.io/docs/concepts/sampling) 🎉 This basically allows connected MCP servers to request completions from Ollama-hosted LLMs.

GiteaMirror commented

2026-04-22 10:42:52 -05:00

@reustle commented on GitHub (May 5, 2025):

Worth mentioning here that the latest MCP spec for remote servers using Streamable HTTP (taking over for SSE) has landed in the Typescript SDK, MCP Inspector, etc. There's still a lack of clients that support it, but backwards compatible servers w/ SSE as well are possible.

https://modelcontextprotocol.io/specification/2025-03-26/changelog#major-changes

@reustle commented on GitHub (May 5, 2025): Worth mentioning here that the latest MCP spec for remote servers using Streamable HTTP (taking over for SSE) has landed in the Typescript SDK, MCP Inspector, etc. There's still a lack of clients that support it, but backwards compatible servers w/ SSE as well are possible. https://modelcontextprotocol.io/specification/2025-03-26/changelog#major-changes

GiteaMirror commented

2026-04-22 10:42:53 -05:00

@bu2 commented on GitHub (May 23, 2025):

I use LibreChat as MCP client powered by local Ollama models and it works fine with Qwen 3 32b.

@bu2 commented on GitHub (May 23, 2025): I use LibreChat as MCP client powered by local Ollama models and it works fine with Qwen 3 32b.

GiteaMirror commented

2026-04-22 10:42:54 -05:00

@rkonfj commented on GitHub (Jun 26, 2025):

@ParthSareen The official modelcontextprotocol/go-sdk is out.

@rkonfj commented on GitHub (Jun 26, 2025): @ParthSareen The official [modelcontextprotocol/go-sdk](https://github.com/modelcontextprotocol/go-sdk) is out.

GiteaMirror commented

2026-04-22 10:42:55 -05:00

@itsPreto commented on GitHub (Jun 30, 2025):

Hi @ParthSareen I feel like there should be enough information and feedback in here to move forward with some kind of decision-- as others have mentioned the ecosystem and overall adoption has grown quite a lot since coming out.

@itsPreto commented on GitHub (Jun 30, 2025): Hi @ParthSareen I feel like there should be enough information and feedback in here to move forward with some kind of decision-- as others have mentioned the ecosystem and overall adoption has grown quite a lot since coming out.

GiteaMirror commented

2026-04-22 10:42:56 -05:00

@ParthSareen commented on GitHub (Jul 6, 2025):

We're working on it! @itsPreto and thanks @cherrydra

@ParthSareen commented on GitHub (Jul 6, 2025): We're working on it! @itsPreto and thanks @cherrydra

GiteaMirror commented

2026-04-22 10:42:57 -05:00

@ncolesummers commented on GitHub (Aug 29, 2025):

Is there an existing branch where this feature is being developed? I would be happy to contribute to this. It would unblock multiple projects I'm working on.

@ncolesummers commented on GitHub (Aug 29, 2025): Is there an existing branch where this feature is being developed? I would be happy to contribute to this. It would unblock multiple projects I'm working on.

GiteaMirror commented

2026-04-22 10:42:58 -05:00

@vielhuber commented on GitHub (Oct 1, 2025):

Do I understand it correctly that in the future Ollama supports MCP (Model Context Protocol) server configuration similar to what Anthropic provides in their API?

Anthropic's Claude API supports MCP server configuration as shown in their MCP Connector documentation (https://docs.claude.com/en/docs/agents-and-tools/mcp-connector), which allows passing MCP servers directly in API requests like this:

mcp_servers: [
  {
    type: "url",
    url: "https://example-server.modelcontextprotocol.io/sse",
    name: "example-mcp",
    authorization_token: "YOUR_TOKEN",
  },
]

Looking at the Ollama API documentation for chat completions (https://docs.ollama.com/api#generate-a-chat-completion), I'm wondering if Ollama supports a similar mcp_servers parameter in their API requests?

Specifically:

Is it possible to pass MCP server configurations directly in the Ollama API request body in the future?
If so, what is the correct syntax/structure for the mcp_servers parameter?
Are there any differences in how Ollama handles MCP servers compared to Anthropic's implementation?

Any clarification or examples would be greatly appreciated.

@vielhuber commented on GitHub (Oct 1, 2025): Do I understand it correctly that in the future Ollama supports MCP (Model Context Protocol) server configuration similar to what Anthropic provides in their API? Anthropic's Claude API supports MCP server configuration as shown in their MCP Connector documentation ([https://docs.claude.com/en/docs/agents-and-tools/mcp-connector](https://docs.claude.com/en/docs/agents-and-tools/mcp-connector)), which allows passing MCP servers directly in API requests like this: ``` mcp_servers: [ { type: "url", url: "https://example-server.modelcontextprotocol.io/sse", name: "example-mcp", authorization_token: "YOUR_TOKEN", }, ] ``` Looking at the Ollama API documentation for chat completions ([https://docs.ollama.com/api#generate-a-chat-completion](https://docs.ollama.com/api#generate-a-chat-completion)), I'm wondering if Ollama supports a similar `mcp_servers` parameter in their API requests? Specifically: - Is it possible to pass MCP server configurations directly in the Ollama API request body in the future? - If so, what is the correct syntax/structure for the `mcp_servers` parameter? - Are there any differences in how Ollama handles MCP servers compared to Anthropic's implementation? Any clarification or examples would be greatly appreciated.

GiteaMirror commented

2026-04-22 10:42:58 -05:00

@Code4me2 commented on GitHub (Nov 15, 2025):

Native MCP Integration for Ollama

Following community requests for native MCP support, this implementation provides server-level integration, works with both the CLI and API, and could easily be adapted to the desktop/mobile app.

Architecture: How MCP is Integrated

MCP Discovery and Registration Pipeline:

Multi-Source Discovery (mcp_registry.go):
- Scans configuration sources in priority order: CLI args → ~/.ollama/mcp-servers.json → /etc/ollama/mcp-servers.json → ENV vars
- Built-in registry with minimal defaults (filesystem server only)
- Dynamic server definition loading with hot-reload capability
- Command resolution through platform-specific resolver (mcp_command_resolver.go)

Server Registration Process (mcp_manager.go):

// At startup, the manager discovers and initializes servers
MCPManager.AddServer(config) →
  ValidateServerConfig() →     // Security validation
  NewMCPClient() →             // Create stdio transport
  client.Initialize() →        // JSON-RPC handshake
  client.ListTools() →         // Tool discovery
  UpdateToolRouting()          // Register tool→server mappings

Tool Injection into Inference Pipeline:
- Tools are dynamically injected at inference time, not stored in prompts
- The --tools flag triggers MCPCodeAPI.InjectContextIntoMessages()
- Progressive context generation based on actual tool usage patterns
- Zero overhead when tools aren't invoked

Core Strengths

1. Native JSON-RPC Implementation (mcp_client.go):

// Direct stdio communication without external SDKs
type MCPClient struct {
    cmd    *exec.Cmd
    stdin  io.WriteCloser
    stdout *bufio.Reader
    responses map[int64]chan *jsonRPCResponse
}

No dependency on Anthropic's SDK or external libraries
Bidirectional stdio transport with proper backpressure handling
Request/response correlation via atomic request IDs
Graceful handling of server crashes with automatic restart

2. Intelligent Tool Orchestration (mcp_manager.go):

// Execution planning for optimal parallelism
func (m *MCPManager) PlanExecution(calls []ToolCall) ExecutionPlan {
    // Analyzes dependencies between tool calls
    // Groups independent calls for parallel execution
    // Respects server-specific concurrency limits
}

Dependency graph analysis for tool call ordering
Parallel execution of independent tools across different servers
Per-server connection pooling with configurable limits
Result caching with TTL to reduce redundant executions

3. Security-First Design (mcp_validator.go + mcp_security_config.go):

// Multi-layer security validation
type SecurityConfig struct {
    AllowedPaths      []string
    BlockedCommands   []string
    MaxExecutionTime  time.Duration
    SandboxMode       bool
}

Path traversal prevention with canonical path validation
Command injection protection via argument sanitization
Resource limits (CPU, memory, execution time)
Optional sandboxing via OS-specific mechanisms

4. Model Integration (mcp_code_api.go):

// Context injection without prompt pollution
func (m *MCPCodeAPI) GenerateMinimalContext(configs []MCPServerConfig) string {
    // Generates enough context for the model to understand available tools
    // Avoids token waste with progressive disclosure
}

Minimal context injection (only tool signatures, not full schemas)
Progressive context expansion based on tool usage
Automatic retry with expanded context on tool resolution failures
Compatible with any model that supports function calling

Performance Metrics

Testing with production workloads shows:

Startup: <100ms to initialize 5 MCP servers
Tool discovery: ~50ms per server (parallelized)
First tool call: ~10ms overhead vs direct execution
Cached results: <1ms retrieval
Memory footprint: ~5MB per active MCP server connection

Integration Points

CLI Integration:

ollama run llama3.2 --tools ~/project  # Auto-discovers filesystem server
ollama run qwen2.5 --tools servers.json  # Custom server configuration

API Integration:

POST /api/chat
{
  "model": "llama3.2",
  "messages": [...],
  "tools": {
    "config_path": "~/.ollama/mcp-servers.json",
    "servers": ["filesystem", "github"]
  }
}

Environment Variables:

OLLAMA_MCP_SERVERS='{"servers":[...]}' ollama run mistral
OLLAMA_MCP_REGISTRY_PATH=/etc/ollama/custom-registry.json ollama serve

Why This Implementation

True Native Integration: Not a wrapper or adapter - MCP is woven into Ollama's core inference loop
Production Ready: Battle-tested with real workloads, proper error handling, and resource management
Zero Configuration: Works out-of-the-box with filesystem tools, no setup required
Extensible: Clean abstractions allow easy addition of new MCP servers without code changes
Performance First: Caching, parallelism, and lazy loading ensure minimal overhead

Current Status & Next Steps

The implementation is complete and actively used in production environments. We've structured it for incremental merging:

Phase 1 - Core Protocol (Ready):

mcp_client.go: JSON-RPC transport
mcp_manager.go: Server lifecycle management
Tests: 95% coverage of core paths

Phase 2 - Discovery & Configuration (Ready):

mcp_registry.go: Server discovery
mcp_config.go: Configuration management
mcp_command_resolver.go: Cross-platform support

Phase 3 - Security & Validation (Ready):

mcp_validator.go: Input validation
mcp_security_config.go: Security policies
Sandboxing integration

Phase 4 - Model Integration (Ready):

mcp_code_api.go: Context injection
CLI flag integration
API endpoint extensions

Phase 5 - Tool loop (ready):

multi-turn tool use by model

Questions for Maintainers

Should we maintain backward compatibility with existing tool-calling implementations during transition?
Preference for configuration format: JSON vs YAML vs TOML?
Should MCP be opt-in via build flag initially or enabled by default?
Any concerns about stdio-based IPC vs alternative transports (gRPC, HTTP)?

This implementation brings Claude-like tool capabilities to every Ollama user while maintaining data sovereignty. @ollama ready to begin the PR process based on your feedback. Working alongside @riteshcode9 & @build4me2

@Code4me2 commented on GitHub (Nov 15, 2025): ## Native MCP Integration for Ollama Following community requests for native MCP support, this implementation provides server-level integration, works with both the CLI and API, and could easily be adapted to the desktop/mobile app. ### Architecture: How MCP is Integrated **MCP Discovery and Registration Pipeline:** 1. **Multi-Source Discovery** (`mcp_registry.go`): - Scans configuration sources in priority order: CLI args → `~/.ollama/mcp-servers.json` → `/etc/ollama/mcp-servers.json` → ENV vars - Built-in registry with minimal defaults (filesystem server only) - Dynamic server definition loading with hot-reload capability - Command resolution through platform-specific resolver (`mcp_command_resolver.go`) 2. **Server Registration Process** (`mcp_manager.go`): ```go // At startup, the manager discovers and initializes servers MCPManager.AddServer(config) → ValidateServerConfig() → // Security validation NewMCPClient() → // Create stdio transport client.Initialize() → // JSON-RPC handshake client.ListTools() → // Tool discovery UpdateToolRouting() // Register tool→server mappings ``` 3. **Tool Injection into Inference Pipeline**: - Tools are dynamically injected at inference time, not stored in prompts - The `--tools` flag triggers `MCPCodeAPI.InjectContextIntoMessages()` - Progressive context generation based on actual tool usage patterns - Zero overhead when tools aren't invoked ### Core Strengths **1. Native JSON-RPC Implementation** (`mcp_client.go`): ```go // Direct stdio communication without external SDKs type MCPClient struct { cmd *exec.Cmd stdin io.WriteCloser stdout *bufio.Reader responses map[int64]chan *jsonRPCResponse } ``` - No dependency on Anthropic's SDK or external libraries - Bidirectional stdio transport with proper backpressure handling - Request/response correlation via atomic request IDs - Graceful handling of server crashes with automatic restart **2. Intelligent Tool Orchestration** (`mcp_manager.go`): ```go // Execution planning for optimal parallelism func (m *MCPManager) PlanExecution(calls []ToolCall) ExecutionPlan { // Analyzes dependencies between tool calls // Groups independent calls for parallel execution // Respects server-specific concurrency limits } ``` - Dependency graph analysis for tool call ordering - Parallel execution of independent tools across different servers - Per-server connection pooling with configurable limits - Result caching with TTL to reduce redundant executions **3. Security-First Design** (`mcp_validator.go` + `mcp_security_config.go`): ```go // Multi-layer security validation type SecurityConfig struct { AllowedPaths []string BlockedCommands []string MaxExecutionTime time.Duration SandboxMode bool } ``` - Path traversal prevention with canonical path validation - Command injection protection via argument sanitization - Resource limits (CPU, memory, execution time) - Optional sandboxing via OS-specific mechanisms **4. Model Integration** (`mcp_code_api.go`): ```go // Context injection without prompt pollution func (m *MCPCodeAPI) GenerateMinimalContext(configs []MCPServerConfig) string { // Generates enough context for the model to understand available tools // Avoids token waste with progressive disclosure } ``` - Minimal context injection (only tool signatures, not full schemas) - Progressive context expansion based on tool usage - Automatic retry with expanded context on tool resolution failures - Compatible with any model that supports function calling ### Performance Metrics Testing with production workloads shows: - **Startup**: <100ms to initialize 5 MCP servers - **Tool discovery**: ~50ms per server (parallelized) - **First tool call**: ~10ms overhead vs direct execution - **Cached results**: <1ms retrieval - **Memory footprint**: ~5MB per active MCP server connection ### Integration Points **CLI Integration**: ```bash ollama run llama3.2 --tools ~/project # Auto-discovers filesystem server ollama run qwen2.5 --tools servers.json # Custom server configuration ``` **API Integration**: ```json POST /api/chat { "model": "llama3.2", "messages": [...], "tools": { "config_path": "~/.ollama/mcp-servers.json", "servers": ["filesystem", "github"] } } ``` **Environment Variables**: ```bash OLLAMA_MCP_SERVERS='{"servers":[...]}' ollama run mistral OLLAMA_MCP_REGISTRY_PATH=/etc/ollama/custom-registry.json ollama serve ``` ### Why This Implementation 1. **True Native Integration**: Not a wrapper or adapter - MCP is woven into Ollama's core inference loop 2. **Production Ready**: Battle-tested with real workloads, proper error handling, and resource management 3. **Zero Configuration**: Works out-of-the-box with filesystem tools, no setup required 4. **Extensible**: Clean abstractions allow easy addition of new MCP servers without code changes 5. **Performance First**: Caching, parallelism, and lazy loading ensure minimal overhead ### Current Status & Next Steps The implementation is complete and actively used in production environments. We've structured it for incremental merging: **Phase 1 - Core Protocol** (Ready): - `mcp_client.go`: JSON-RPC transport - `mcp_manager.go`: Server lifecycle management - Tests: 95% coverage of core paths **Phase 2 - Discovery & Configuration** (Ready): - `mcp_registry.go`: Server discovery - `mcp_config.go`: Configuration management - `mcp_command_resolver.go`: Cross-platform support **Phase 3 - Security & Validation** (Ready): - `mcp_validator.go`: Input validation - `mcp_security_config.go`: Security policies - Sandboxing integration **Phase 4 - Model Integration** (Ready): - `mcp_code_api.go`: Context injection - CLI flag integration - API endpoint extensions **Phase 5 - Tool loop** (ready): - multi-turn tool use by model ### Questions for Maintainers 1. Should we maintain backward compatibility with existing tool-calling implementations during transition? 2. Preference for configuration format: JSON vs YAML vs TOML? 3. Should MCP be opt-in via build flag initially or enabled by default? 4. Any concerns about stdio-based IPC vs alternative transports (gRPC, HTTP)? This implementation brings Claude-like tool capabilities to every Ollama user while maintaining data sovereignty. @ollama ready to begin the PR process based on your feedback. Working alongside @riteshcode9 & @build4me2

GiteaMirror commented

2026-04-22 10:42:59 -05:00

@bartolli commented on GitHub (Nov 15, 2025):

Hi there,

I built a small PoC that lets the desktop Ollama app connect to external tools and data sources through the MCP.

Made it for personal use and wanted to check whether the @ollama team would find this valuable. If yes, I will open a PR.

It’s based on Anthropic’s Go SDK and integrates into the app lifecycle.

https://github.com/user-attachments/assets/487bf8e1-ae3a-4e39-ac41-77c113e41caf

Implementation details

Database changes
• Schema migrated to v13 via migrateV12ToV13()
• Added mcp_servers TEXT NOT NULL DEFAULT '{}' column to the settings table
• Defaults to ~/.ollama/mcp.json via defaultMCPConfigPath()
• Migration checks for column existence before running ALTER TABLE

Architecture
• MCP client (app/mcp/client.go) uses stdio transport via exec.Command() to spawn MCP servers
• Each server maintains its own *mcp.ClientSession inside a map[string]
• Tool-adapter pattern: MCPTool implements Ollama’s Tool interface and wraps CallToolResult

Tool registration
• Tools use namespaced pattern mcp__[server_name]__[tool_name] via FormatMCPToolName()
• Dynamic registration at chat time through registerMCPTools() in ui/ui.go
• Registered only when no attachments are present to avoid conflicts with multimodal tools

API surface
• Added mcpToolLister interface to ui.Server for dependency injection
• Methods: ListTools(), GetServerNames(), CallTool()
• No changes to core server code; all integration stays in the app layer

Content-type handling
• MCP content types (TextContent, ImageContent, AudioContent, ResourceLink, EmbeddedResource) mapped to Ollama’s display format in formatToolResult()
• Structured outputs fall back to JSON marshaling

Session lifecycle
• Servers spawn on app init (app.go:81)
• Clean shutdown via Disconnect() on app termination
• Failed server connections are logged but do not block app startup

Configuration
• JSON config supports command, args[], and env{} per server
• Environment variables merge with the parent process env

Testing
• Added unit tests for tool-name formatting/parsing and execution flow
• No integration tests yet; MCP servers are external processes

Impact
• No changes to /server or core inference paths
• Tool calls route through the existing execution pipeline
• Settings UI extended with a file picker for the config path
• TypeScript types regenerated for Settings state

This keeps MCP as an optional feature in the desktop app without affecting the core Ollama server.

@bartolli commented on GitHub (Nov 15, 2025): Hi there, I built a small PoC that lets the desktop Ollama app connect to external tools and data sources through the MCP. Made it for personal use and wanted to check whether the @ollama team would find this valuable. If yes, I will open a PR. It’s based on Anthropic’s Go SDK and integrates into the app lifecycle. https://github.com/user-attachments/assets/487bf8e1-ae3a-4e39-ac41-77c113e41caf Implementation details Database changes • Schema migrated to v13 via migrateV12ToV13() • Added mcp_servers TEXT NOT NULL DEFAULT '{}' column to the settings table • Defaults to ~/.ollama/mcp.json via defaultMCPConfigPath() • Migration checks for column existence before running ALTER TABLE Architecture • MCP client (app/mcp/client.go) uses stdio transport via exec.Command() to spawn MCP servers • Each server maintains its own *mcp.ClientSession inside a map[string] • Tool-adapter pattern: MCPTool implements Ollama’s Tool interface and wraps CallToolResult Tool registration • Tools use namespaced pattern mcp__[server_name]__[tool_name] via FormatMCPToolName() • Dynamic registration at chat time through registerMCPTools() in ui/ui.go • Registered only when no attachments are present to avoid conflicts with multimodal tools API surface • Added mcpToolLister interface to ui.Server for dependency injection • Methods: ListTools(), GetServerNames(), CallTool() • No changes to core server code; all integration stays in the app layer Content-type handling • MCP content types (TextContent, ImageContent, AudioContent, ResourceLink, EmbeddedResource) mapped to Ollama’s display format in formatToolResult() • Structured outputs fall back to JSON marshaling Session lifecycle • Servers spawn on app init (app.go:81) • Clean shutdown via Disconnect() on app termination • Failed server connections are logged but do not block app startup Configuration • JSON config supports command, args[], and env{} per server • Environment variables merge with the parent process env Testing • Added unit tests for tool-name formatting/parsing and execution flow • No integration tests yet; MCP servers are external processes Impact • No changes to /server or core inference paths • Tool calls route through the existing execution pipeline • Settings UI extended with a file picker for the config path • TypeScript types regenerated for Settings state This keeps MCP as an optional feature in the desktop app without affecting the core Ollama server.

GiteaMirror commented

2026-04-22 10:43:01 -05:00

@Code4me2 commented on GitHub (Nov 15, 2025):

Hi there,

I built a small PoC that lets the desktop Ollama app connect to external tools and data sources through the MCP.

Made it for personal use and wanted to check whether the @ollama team would find this valuable. If yes, I will open a PR.

It’s based on Anthropic’s Go SDK and integrates into the app lifecycle.
ollama_macos.mov

Implementation details

Database changes • Schema migrated to v13 via migrateV12ToV13() • Added mcp_servers TEXT NOT NULL DEFAULT '{}' column to the settings table • Defaults to ~/.ollama/mcp.json via defaultMCPConfigPath() • Migration checks for column existence before running ALTER TABLE

Architecture • MCP client (app/mcp/client.go) uses stdio transport via exec.Command() to spawn MCP servers • Each server maintains its own *mcp.ClientSession inside a map[string] • Tool-adapter pattern: MCPTool implements Ollama’s Tool interface and wraps CallToolResult

Tool registration • Tools use namespaced pattern mcp__[server_name]__[tool_name] via FormatMCPToolName() • Dynamic registration at chat time through registerMCPTools() in ui/ui.go • Registered only when no attachments are present to avoid conflicts with multimodal tools

API surface • Added mcpToolLister interface to ui.Server for dependency injection • Methods: ListTools(), GetServerNames(), CallTool() • No changes to core server code; all integration stays in the app layer

Content-type handling • MCP content types (TextContent, ImageContent, AudioContent, ResourceLink, EmbeddedResource) mapped to Ollama’s display format in formatToolResult() • Structured outputs fall back to JSON marshaling

Session lifecycle • Servers spawn on app init (app.go:81) • Clean shutdown via Disconnect() on app termination • Failed server connections are logged but do not block app startup

Configuration • JSON config supports command, args[], and env{} per server • Environment variables merge with the parent process env

Testing • Added unit tests for tool-name formatting/parsing and execution flow • No integration tests yet; MCP servers are external processes

Impact • No changes to /server or core inference paths • Tool calls route through the existing execution pipeline • Settings UI extended with a file picker for the config path • TypeScript types regenerated for Settings state

This keeps MCP as an optional feature in the desktop app without affecting the core Ollama server.

This is a great UI implementation! The desktop integration looks really clean. Our approaches could actually complement each other well - the server-level integration we've built could provide the backend, while your desktop UI work could enhance the user experience for desktop users. Would love to collaborate once we get maintainer feedback on the best path forward!

@Code4me2 commented on GitHub (Nov 15, 2025): > Hi there, > > I built a small PoC that lets the desktop Ollama app connect to external tools and data sources through the MCP. > > Made it for personal use and wanted to check whether the [@ollama](https://github.com/ollama) team would find this valuable. If yes, I will open a PR. > > It’s based on Anthropic’s Go SDK and integrates into the app lifecycle. > ollama_macos.mov > > Implementation details > > Database changes • Schema migrated to v13 via migrateV12ToV13() • Added mcp_servers TEXT NOT NULL DEFAULT '{}' column to the settings table • Defaults to ~/.ollama/mcp.json via defaultMCPConfigPath() • Migration checks for column existence before running ALTER TABLE > > Architecture • MCP client (app/mcp/client.go) uses stdio transport via exec.Command() to spawn MCP servers • Each server maintains its own *mcp.ClientSession inside a map[string] • Tool-adapter pattern: MCPTool implements Ollama’s Tool interface and wraps CallToolResult > > Tool registration • Tools use namespaced pattern mcp__[server_name]__[tool_name] via FormatMCPToolName() • Dynamic registration at chat time through registerMCPTools() in ui/ui.go • Registered only when no attachments are present to avoid conflicts with multimodal tools > > API surface • Added mcpToolLister interface to ui.Server for dependency injection • Methods: ListTools(), GetServerNames(), CallTool() • No changes to core server code; all integration stays in the app layer > > Content-type handling • MCP content types (TextContent, ImageContent, AudioContent, ResourceLink, EmbeddedResource) mapped to Ollama’s display format in formatToolResult() • Structured outputs fall back to JSON marshaling > > Session lifecycle • Servers spawn on app init (app.go:81) • Clean shutdown via Disconnect() on app termination • Failed server connections are logged but do not block app startup > > Configuration • JSON config supports command, args[], and env{} per server • Environment variables merge with the parent process env > > Testing • Added unit tests for tool-name formatting/parsing and execution flow • No integration tests yet; MCP servers are external processes > > Impact • No changes to /server or core inference paths • Tool calls route through the existing execution pipeline • Settings UI extended with a file picker for the config path • TypeScript types regenerated for Settings state > > This keeps MCP as an optional feature in the desktop app without affecting the core Ollama server. This is a great UI implementation! The desktop integration looks really clean. Our approaches could actually complement each other well - the server-level integration we've built could provide the backend, while your desktop UI work could enhance the user experience for desktop users. Would love to collaborate once we get maintainer feedback on the best path forward!

GiteaMirror commented

2026-04-22 10:43:04 -05:00

@vielhuber commented on GitHub (Nov 15, 2025):

Should we maintain backward compatibility with existing tool-calling implementations during transition?

Backward compatibility is not needed in my opinion. Given that this is a relatively new area and still evolving, it seems reasonable to prioritize a clean and coherent MCP-based design over carrying forward legacy behavior. This keeps the implementation simpler, avoids confusing edge cases, and encourages users to adopt the new approach directly instead of relying on transitional shims.

Preference for configuration format: JSON vs YAML vs TOML?

JSON should be used as the default configuration format, in line with what most other tools and ecosystems do. It is widely understood, well supported across languages, and keeps the configuration story straightforward. Other formats could always be added later if there’s a strong need, but starting with JSON as the primary option keeps things consistent and predictable.

Should MCP be opt-in via build flag initially or enabled by default?

It should be enabled by default. Treating MCP as a first-class, always-on capability sends a clear signal that this is the standard way forward rather than an experimental or optional add-on. Users who do not need it can simply ignore the functionality, while those who do benefit from having it available out of the box without extra build-time configuration.

Any concerns about stdio-based IPC vs alternative transports (gRPC, HTTP)?

Both should be supported first class. Stdio is a good default for simple, local integrations and aligns well with many existing tools, but gRPC and HTTP are important for more complex or distributed setups. Treating these transports as equally supported options gives users the flexibility to choose what best fits their environment and deployment model, instead of locking them into a single IPC mechanism.

@vielhuber commented on GitHub (Nov 15, 2025): > Should we maintain backward compatibility with existing tool-calling implementations during transition? Backward compatibility is not needed in my opinion. Given that this is a relatively new area and still evolving, it seems reasonable to prioritize a clean and coherent MCP-based design over carrying forward legacy behavior. This keeps the implementation simpler, avoids confusing edge cases, and encourages users to adopt the new approach directly instead of relying on transitional shims. > Preference for configuration format: JSON vs YAML vs TOML? JSON should be used as the default configuration format, in line with what most other tools and ecosystems do. It is widely understood, well supported across languages, and keeps the configuration story straightforward. Other formats could always be added later if there’s a strong need, but starting with JSON as the primary option keeps things consistent and predictable. > Should MCP be opt-in via build flag initially or enabled by default? It should be enabled by default. Treating MCP as a first-class, always-on capability sends a clear signal that this is the standard way forward rather than an experimental or optional add-on. Users who do not need it can simply ignore the functionality, while those who do benefit from having it available out of the box without extra build-time configuration. > Any concerns about stdio-based IPC vs alternative transports (gRPC, HTTP)? Both should be supported first class. Stdio is a good default for simple, local integrations and aligns well with many existing tools, but gRPC and HTTP are important for more complex or distributed setups. Treating these transports as equally supported options gives users the flexibility to choose what best fits their environment and deployment model, instead of locking them into a single IPC mechanism.

GiteaMirror commented

2026-04-22 10:43:06 -05:00

@libreosley-stack commented on GitHub (Dec 5, 2025):

Native MCP Integration for Ollama

Following community requests for native MCP support, this implementation provides server-level integration, works with both the CLI and API, and could easily be adapted to the desktop/mobile app.

Architecture: How MCP is Integrated

MCP Discovery and Registration Pipeline:

Multi-Source Discovery (mcp_registry.go):

Scans configuration sources in priority order: CLI args → ~/.ollama/mcp-servers.json → /etc/ollama/mcp-servers.json → ENV vars

Built-in registry with minimal defaults (filesystem server only)

Dynamic server definition loading with hot-reload capability

Command resolution through platform-specific resolver (mcp_command_resolver.go)

Server Registration Process (mcp_manager.go):
// At startup, the manager discovers and initializes servers
MCPManager.AddServer(config) →
ValidateServerConfig() → // Security validation
NewMCPClient() → // Create stdio transport
client.Initialize() → // JSON-RPC handshake
client.ListTools() → // Tool discovery
UpdateToolRouting() // Register tool→server mappings

Tool Injection into Inference Pipeline:

Tools are dynamically injected at inference time, not stored in prompts

The --tools flag triggers MCPCodeAPI.InjectContextIntoMessages()

Progressive context generation based on actual tool usage patterns

Zero overhead when tools aren't invoked

Core Strengths

1. Native JSON-RPC Implementation (mcp_client.go):

// Direct stdio communication without external SDKs
type MCPClient struct {
cmd *exec.Cmd
stdin io.WriteCloser
stdout *bufio.Reader
responses map[int64]chan *jsonRPCResponse
}

No dependency on Anthropic's SDK or external libraries

Bidirectional stdio transport with proper backpressure handling

Request/response correlation via atomic request IDs

Graceful handling of server crashes with automatic restart

2. Intelligent Tool Orchestration (mcp_manager.go):

// Execution planning for optimal parallelism
func (m *MCPManager) PlanExecution(calls []ToolCall) ExecutionPlan {
// Analyzes dependencies between tool calls
// Groups independent calls for parallel execution
// Respects server-specific concurrency limits
}

Dependency graph analysis for tool call ordering

Parallel execution of independent tools across different servers

Per-server connection pooling with configurable limits

Result caching with TTL to reduce redundant executions

3. Security-First Design (mcp_validator.go + mcp_security_config.go):

// Multi-layer security validation
type SecurityConfig struct {
AllowedPaths []string
BlockedCommands []string
MaxExecutionTime time.Duration
SandboxMode bool
}

Path traversal prevention with canonical path validation

Command injection protection via argument sanitization

Resource limits (CPU, memory, execution time)

Optional sandboxing via OS-specific mechanisms

4. Model Integration (mcp_code_api.go):

// Context injection without prompt pollution
func (m *MCPCodeAPI) GenerateMinimalContext(configs []MCPServerConfig) string {
// Generates enough context for the model to understand available tools
// Avoids token waste with progressive disclosure
}

Minimal context injection (only tool signatures, not full schemas)

Progressive context expansion based on tool usage

Automatic retry with expanded context on tool resolution failures

Compatible with any model that supports function calling

Performance Metrics

Testing with production workloads shows:

Startup: <100ms to initialize 5 MCP servers

Tool discovery: ~50ms per server (parallelized)

First tool call: ~10ms overhead vs direct execution

Cached results: <1ms retrieval

Memory footprint: ~5MB per active MCP server connection

Integration Points

CLI Integration:

ollama run llama3.2 --tools ~/project # Auto-discovers filesystem server
ollama run qwen2.5 --tools servers.json # Custom server configuration
API Integration:

POST /api/chat
{
"model": "llama3.2",
"messages": [...],
"tools": {
"config_path": "~/.ollama/mcp-servers.json",
"servers": ["filesystem", "github"]
}
}
Environment Variables:

OLLAMA_MCP_SERVERS='{"servers":[...]}' ollama run mistral
OLLAMA_MCP_REGISTRY_PATH=/etc/ollama/custom-registry.json ollama serve

Why This Implementation

True Native Integration: Not a wrapper or adapter - MCP is woven into Ollama's core inference loop

Production Ready: Battle-tested with real workloads, proper error handling, and resource management

Zero Configuration: Works out-of-the-box with filesystem tools, no setup required

Extensible: Clean abstractions allow easy addition of new MCP servers without code changes

Performance First: Caching, parallelism, and lazy loading ensure minimal overhead

Current Status & Next Steps

The implementation is complete and actively used in production environments. We've structured it for incremental merging:

Phase 1 - Core Protocol (Ready):

mcp_client.go: JSON-RPC transport

mcp_manager.go: Server lifecycle management

Tests: 95% coverage of core paths

Phase 2 - Discovery & Configuration (Ready):

mcp_registry.go: Server discovery

mcp_config.go: Configuration management

mcp_command_resolver.go: Cross-platform support

Phase 3 - Security & Validation (Ready):

mcp_validator.go: Input validation

mcp_security_config.go: Security policies

Sandboxing integration

Phase 4 - Model Integration (Ready):

mcp_code_api.go: Context injection

CLI flag integration

API endpoint extensions

Phase 5 - Tool loop (ready):

multi-turn tool use by model

Questions for Maintainers

Should we maintain backward compatibility with existing tool-calling implementations during transition?

Preference for configuration format: JSON vs YAML vs TOML?

Should MCP be opt-in via build flag initially or enabled by default?

Any concerns about stdio-based IPC vs alternative transports (gRPC, HTTP)?

This implementation brings Claude-like tool capabilities to every Ollama user while maintaining data sovereignty. @ollama ready to begin the PR process based on your feedback. Working alongside @riteshcode9 & @build4me2

I could really do with this is there any way of getting a detailed guide of what and where to place things and what to add where? so i can implement this please?

Thought i would update this to say a very big thank you and i got this work and am thankfully to all the work you put into this.

@libreosley-stack commented on GitHub (Dec 5, 2025): > ## Native MCP Integration for Ollama > Following community requests for native MCP support, this implementation provides server-level integration, works with both the CLI and API, and could easily be adapted to the desktop/mobile app. > > ### Architecture: How MCP is Integrated > **MCP Discovery and Registration Pipeline:** > > 1. **Multi-Source Discovery** (`mcp_registry.go`): > > * Scans configuration sources in priority order: CLI args → `~/.ollama/mcp-servers.json` → `/etc/ollama/mcp-servers.json` → ENV vars > * Built-in registry with minimal defaults (filesystem server only) > * Dynamic server definition loading with hot-reload capability > * Command resolution through platform-specific resolver (`mcp_command_resolver.go`) > 2. **Server Registration Process** (`mcp_manager.go`): > // At startup, the manager discovers and initializes servers > MCPManager.AddServer(config) → > ValidateServerConfig() → // Security validation > NewMCPClient() → // Create stdio transport > client.Initialize() → // JSON-RPC handshake > client.ListTools() → // Tool discovery > UpdateToolRouting() // Register tool→server mappings > 3. **Tool Injection into Inference Pipeline**: > > * Tools are dynamically injected at inference time, not stored in prompts > * The `--tools` flag triggers `MCPCodeAPI.InjectContextIntoMessages()` > * Progressive context generation based on actual tool usage patterns > * Zero overhead when tools aren't invoked > > ### Core Strengths > **1. Native JSON-RPC Implementation** (`mcp_client.go`): > > // Direct stdio communication without external SDKs > type MCPClient struct { > cmd *exec.Cmd > stdin io.WriteCloser > stdout *bufio.Reader > responses map[int64]chan *jsonRPCResponse > } > * No dependency on Anthropic's SDK or external libraries > * Bidirectional stdio transport with proper backpressure handling > * Request/response correlation via atomic request IDs > * Graceful handling of server crashes with automatic restart > > **2. Intelligent Tool Orchestration** (`mcp_manager.go`): > > // Execution planning for optimal parallelism > func (m *MCPManager) PlanExecution(calls []ToolCall) ExecutionPlan { > // Analyzes dependencies between tool calls > // Groups independent calls for parallel execution > // Respects server-specific concurrency limits > } > * Dependency graph analysis for tool call ordering > * Parallel execution of independent tools across different servers > * Per-server connection pooling with configurable limits > * Result caching with TTL to reduce redundant executions > > **3. Security-First Design** (`mcp_validator.go` + `mcp_security_config.go`): > > // Multi-layer security validation > type SecurityConfig struct { > AllowedPaths []string > BlockedCommands []string > MaxExecutionTime time.Duration > SandboxMode bool > } > * Path traversal prevention with canonical path validation > * Command injection protection via argument sanitization > * Resource limits (CPU, memory, execution time) > * Optional sandboxing via OS-specific mechanisms > > **4. Model Integration** (`mcp_code_api.go`): > > // Context injection without prompt pollution > func (m *MCPCodeAPI) GenerateMinimalContext(configs []MCPServerConfig) string { > // Generates enough context for the model to understand available tools > // Avoids token waste with progressive disclosure > } > * Minimal context injection (only tool signatures, not full schemas) > * Progressive context expansion based on tool usage > * Automatic retry with expanded context on tool resolution failures > * Compatible with any model that supports function calling > > ### Performance Metrics > Testing with production workloads shows: > > * **Startup**: <100ms to initialize 5 MCP servers > * **Tool discovery**: ~50ms per server (parallelized) > * **First tool call**: ~10ms overhead vs direct execution > * **Cached results**: <1ms retrieval > * **Memory footprint**: ~5MB per active MCP server connection > > ### Integration Points > **CLI Integration**: > > ollama run llama3.2 --tools ~/project # Auto-discovers filesystem server > ollama run qwen2.5 --tools servers.json # Custom server configuration > **API Integration**: > > POST /api/chat > { > "model": "llama3.2", > "messages": [...], > "tools": { > "config_path": "~/.ollama/mcp-servers.json", > "servers": ["filesystem", "github"] > } > } > **Environment Variables**: > > OLLAMA_MCP_SERVERS='{"servers":[...]}' ollama run mistral > OLLAMA_MCP_REGISTRY_PATH=/etc/ollama/custom-registry.json ollama serve > ### Why This Implementation > 1. **True Native Integration**: Not a wrapper or adapter - MCP is woven into Ollama's core inference loop > 2. **Production Ready**: Battle-tested with real workloads, proper error handling, and resource management > 3. **Zero Configuration**: Works out-of-the-box with filesystem tools, no setup required > 4. **Extensible**: Clean abstractions allow easy addition of new MCP servers without code changes > 5. **Performance First**: Caching, parallelism, and lazy loading ensure minimal overhead > > ### Current Status & Next Steps > The implementation is complete and actively used in production environments. We've structured it for incremental merging: > > **Phase 1 - Core Protocol** (Ready): > > * `mcp_client.go`: JSON-RPC transport > * `mcp_manager.go`: Server lifecycle management > * Tests: 95% coverage of core paths > > **Phase 2 - Discovery & Configuration** (Ready): > > * `mcp_registry.go`: Server discovery > * `mcp_config.go`: Configuration management > * `mcp_command_resolver.go`: Cross-platform support > > **Phase 3 - Security & Validation** (Ready): > > * `mcp_validator.go`: Input validation > * `mcp_security_config.go`: Security policies > * Sandboxing integration > > **Phase 4 - Model Integration** (Ready): > > * `mcp_code_api.go`: Context injection > * CLI flag integration > * API endpoint extensions > > **Phase 5 - Tool loop** (ready): > > * multi-turn tool use by model > > ### Questions for Maintainers > 1. Should we maintain backward compatibility with existing tool-calling implementations during transition? > 2. Preference for configuration format: JSON vs YAML vs TOML? > 3. Should MCP be opt-in via build flag initially or enabled by default? > 4. Any concerns about stdio-based IPC vs alternative transports (gRPC, HTTP)? > > This implementation brings Claude-like tool capabilities to every Ollama user while maintaining data sovereignty. [@ollama](https://github.com/ollama) ready to begin the PR process based on your feedback. Working alongside [@riteshcode9](https://github.com/riteshcode9) & [@build4me2](https://github.com/build4me2) I could really do with this is there any way of getting a detailed guide of what and where to place things and what to add where? so i can implement this please? Thought i would update this to say a very big thank you and i got this work and am thankfully to all the work you put into this.

GiteaMirror commented

2026-04-22 10:43:08 -05:00

@Code4me2 commented on GitHub (Dec 7, 2025):

I haven't open sourced the fork yet, I was waiting to hear back from the ollama code maintainers. I will make the fork public soon! Did you find another implementation somewhere else?

@Code4me2 commented on GitHub (Dec 7, 2025): I haven't open sourced the fork yet, I was waiting to hear back from the ollama code maintainers. I will make the fork public soon! Did you find another implementation somewhere else?

GiteaMirror commented

2026-04-22 10:43:09 -05:00

@libreosley-stack commented on GitHub (Dec 8, 2025):

I haven't open sourced the fork yet, I was waiting to hear back from the ollama code maintainers. I will make the fork public soon! Did you find another implementation somewhere else?

no I copied your post and handed it to one of my guys and asked if they could try it on a local install of ollama and in a few hours they came back saying they had got it working just from the information in your post. we had to play with it a bit to get the output as we wanted it but got it working then we added markdown support on the output which worked then we tried adding a embedding AI for RAG and that Brock it and we ended up going with langchain nut it works 100% and in CLI witch was our man area we needed it.

@libreosley-stack commented on GitHub (Dec 8, 2025): > I haven't open sourced the fork yet, I was waiting to hear back from the ollama code maintainers. I will make the fork public soon! Did you find another implementation somewhere else? no I copied your post and handed it to one of my guys and asked if they could try it on a local install of ollama and in a few hours they came back saying they had got it working just from the information in your post. we had to play with it a bit to get the output as we wanted it but got it working then we added markdown support on the output which worked then we tried adding a embedding AI for RAG and that Brock it and we ended up going with langchain nut it works 100% and in CLI witch was our man area we needed it.

GiteaMirror commented

2026-04-22 10:43:10 -05:00

@Code4me2 commented on GitHub (Dec 8, 2025):

no I copied your post and handed it to one of my guys and asked if they could try it on a local install of ollama and in a few hours they came back saying they had got it working just from the information in your post. we had to play with it a bit to get the output as we wanted it but got it working then we added markdown support on the output which worked then we tried adding a embedding AI for RAG and that Brock it and we ended up going with langchain nut it works 100% and in CLI witch was our man area we needed it.

Glad to hear it! I am curious, what broke it specifically? Embeddings? I am completing a rebase on top of the most recent ollama to submit a PR and make the fork public. Any issue specifics you could share I'd be greatful

@Code4me2 commented on GitHub (Dec 8, 2025): > no I copied your post and handed it to one of my guys and asked if they could try it on a local install of ollama and in a few hours they came back saying they had got it working just from the information in your post. we had to play with it a bit to get the output as we wanted it but got it working then we added markdown support on the output which worked then we tried adding a embedding AI for RAG and that Brock it and we ended up going with langchain nut it works 100% and in CLI witch was our man area we needed it. Glad to hear it! I am curious, what broke it specifically? Embeddings? I am completing a rebase on top of the most recent ollama to submit a PR and make the fork public. Any issue specifics you could share I'd be greatful

GiteaMirror commented

2026-04-22 10:43:10 -05:00

@Code4me2 commented on GitHub (Dec 8, 2025):

Also I'd note on here that I am implementing a better permission system so that autonomous loops can include human in the loop processes for more sensitive MCP tools.

@Code4me2 commented on GitHub (Dec 8, 2025): Also I'd note on here that I am implementing a better permission system so that autonomous loops can include human in the loop processes for more sensitive MCP tools.

GiteaMirror commented

2026-04-22 10:43:10 -05:00

@libreosley-stack commented on GitHub (Dec 8, 2025):

Also I'd note on here that I am implementing a better permission system so that autonomous loops can include human in the loop processes for more sensitive MCP tools.

let's say the issue was an in-house issue it wouldn't get repeated with anyone else.

@libreosley-stack commented on GitHub (Dec 8, 2025): > Also I'd note on here that I am implementing a better permission system so that autonomous loops can include human in the loop processes for more sensitive MCP tools. let's say the issue was an in-house issue it wouldn't get repeated with anyone else.

GiteaMirror commented

2026-04-22 10:43:11 -05:00

@kevinkaylie commented on GitHub (Mar 25, 2026):

Hey! Not directly related to this issue, but you might be interested in AgentNexus — an open-source implementation of agent-to-agent communication with a key difference from A2A:

DID-based identity (decentralized, persistent) vs URL-based addressing in A2A
Federated Relay network — supports private deployment, works behind NAT/firewall
Native MCP integration — 12 built-in tools, works with any MCP-compliant agent
Encryption by default — Ed25519 signatures + X25519 ECDH key exchange

The key insight: A2A solves "how do agents discover each other?" but relies on URLs that depend on the platform staying alive. DID-based addressing means even if the platform goes down, your agent's identity persists.

If you're working on MCP support, AgentNexus could provide the transport layer — happy to chat more about this!

@kevinkaylie commented on GitHub (Mar 25, 2026): Hey! Not directly related to this issue, but you might be interested in **[AgentNexus](https://github.com/kevinkaylie/AgentNexus)** — an open-source implementation of agent-to-agent communication with a key difference from A2A: - **DID-based identity** (decentralized, persistent) vs URL-based addressing in A2A - **Federated Relay network** — supports private deployment, works behind NAT/firewall - **Native MCP integration** — 12 built-in tools, works with any MCP-compliant agent - **Encryption by default** — Ed25519 signatures + X25519 ECDH key exchange The key insight: A2A solves "how do agents discover each other?" but relies on URLs that depend on the platform staying alive. DID-based addressing means **even if the platform goes down, your agent's identity persists**. If you're working on MCP support, AgentNexus could provide the transport layer — happy to chat more about this!

Sign in to join this conversation.

Branches Tags

main

dhiltgen/ci

dhiltgen/llama-runner

parth-launch-codex-app

hoyyeva/anthropic-local-image-path

hoyyeva/anthropic-reference-images-path

parth-anthropic-reference-images-path

brucemacd/download-before-remove

hoyyeva/editor-config-repair

parth-mlx-decode-checkpoints

hoyyeva/fix-codex-model-metadata-warning

hoyyeva/qwen

parth/hide-claude-desktop-till-release

hoyyeva/opencode-image-modality

parth-add-claude-code-autoinstall

release_v0.22.0

pdevine/manifest-list

codex/fix-codex-model-metadata-warning

pdevine/addressable-manifest

brucemacd/launch-fetch-reccomended

jmorganca/llama-compat

launch-copilot-cli

hoyyeva/opencode-thinking

release_v0.20.7

parth-auto-save-backup

parth-test

jmorganca/gemma4-audio-replacements

fix-manifest-digest-on-pull

hoyyeva/vscode-improve

brucemacd/install-server-wait

parth/update-claude-docs

brucemac/start-ap-install

pdevine/mlx-update

pdevine/qwen35_vision

drifkin/api-show-fallback

mintlify/image-generation-1773352582

hoyyeva/server-context-length-local-config

jmorganca/faster-reptition-penalties

jmorganca/convert-nemotron

parth-pi-thinking

pdevine/sampling-penalties

jmorganca/fix-create-quantization-memory

dongchen/resumable_transfer_fix

pdevine/sampling-cache-error

jessegross/mlx-usage

hoyyeva/openclaw-config

hoyyeva/app-html

pdevine/qwen3next

brucemacd/sign-sh-install

brucemacd/tui-update

brucemacd/usage-api

jmorganca/launch-empty

fix-app-dist-embed

mxyng/mlx-compile

mxyng/mlx-quant

mxyng/mlx-glm4.7

mxyng/mlx

brucemacd/simplify-model-picker

jmorganca/qwen3-concurrent

fix-glm-4.7-flash-mla-config

drifkin/qwen3-coder-opening-tag

brucemacd/usage-cli

fix-cuda12-fattn-shmem

ollama-imagegen-docs

parth/fix-multiline-inputs

brucemacd/config-docs

mxyng/model-files

mxyng/simple-execute

fix-imagegen-ollama-models

mxyng/async-upload

jmorganca/lazy-no-dtype-changes

imagegen-auto-detect-create

parth/decrease-concurrent-download-hf

fix-mlx-quantize-init

jmorganca/x-cleanup

usage

imagegen-readme

jmorganca/glm-image

mlx-gpu-cd

jmorganca/imagegen-modelfile

parth/agent-skills

parth/agent-allowlist

parth/signed-in-offline

parth/agents

parth/fix-context-chopping

improve-cloud-flow

parth/add-models-websearch

parth/prompt-renderer-mcp

jmorganca/native-settings

jmorganca/download-stream-hash

jmorganca/client2-rebased

brucemacd/oai-chat-req-multipart

jessegross/multi_chunk_reserve

grace/additional-omit-empty

grace/mistral-3-large

mxyng/tokenizer2

mxyng/tokenizer

jessegross/flash

hoyyeva/windows-nacked-app

mxyng/cleanup-attention

grace/deepseek-parser

hoyyeva/remember-unsent-prompt

parth/add-lfs-pointer-error-conversion

parth/olmo2-test2

hoyyeva/ollama-launchagent-plist

nicole/olmo-model

parth/olmo-test

mxyng/remove-embedded

parth/render-template

jmorganca/intellect-3

parth/remove-prealloc-linter

jmorganca/cmd-eval

nicole/nomic-embed-text-fix

mxyng/lint-2

hoyyeva/add-gemini-3-pro-preview

hoyyeva/load-model-list

mxyng/expand-path

mxyng/environ-2

hoyyeva/deeplink-json-encoding

parth/improve-tool-calling-tests

hoyyeva/conversation

hoyyeva/assistant-edit-response

hoyyeva/thinking

origin/brucemacd/invalid-char-i-err

parth/improve-tool-calling

jmorganca/required-omitempty

grace/qwen3-vl-tests

mxyng/iter-client

parth/docs-readme

nicole/embed-test

pdevine/integration-benchstat

parth/remove-generate-cmd

parth/add-toolcall-id

mxyng/server-tests

jmorganca/glm-4.6

jmorganca/gin-h-compat

drifkin/stable-tool-args

pdevine/qwen3-more-thinking

parth/add-websearch-client

nicole/websearch_local

jmorganca/qwen3-coder-updates

grace/deepseek-v3-migration-tests

mxyng/fix-create

jmorganca/cloud-errors

pdevine/parser-tidy

revert-12233-parth/simplify-entrypoints-runner

parth/enable-so-gpt-oss

brucemacd/qwen3vl

jmorganca/readme-simplify

parth/gpt-oss-structured-outputs

revert-12039-jmorganca/tools-braces

mxyng/embeddings

mxyng/gguf

mxyng/benchmark

mxyng/types-null

parth/move-parsing

mxyng/gemma2

jmorganca/docs

mxyng/16-bit

mxyng/create-stdin

pdevine/authorizedkeys

mxyng/quant

parth/opt-in-error-context-window

brucemacd/cache-models

brucemacd/runner-completion

jmorganca/llama-update-6

brucemacd/benchmark-list

brucemacd/partial-read-caps

parth/deepseek-r1-tools

mxyng/omit-array

parth/tool-prefix-temp

brucemacd/runner-test

jmorganca/qwen25vl

brucemacd/model-forward-test-ext

parth/python-function-parsing

jmorganca/cuda-compression-none

drifkin/num-parallel

drifkin/chat-truncation-fix

jmorganca/sync

parth/python-tools-calling

drifkin/array-head-count

brucemacd/create-no-loop

parth/server-enable-content-stream-with-tools

qwen25omni

mxyng/v3

brucemacd/ropeconfig

jmorganca/silence-tokenizer

parth/sample-so-test

parth/sampling-structured-outputs

brucemacd/doc-go-engine

parth/constrained-sampling-json

jmorganca/mistral-wip

brucemacd/mistral-small-convert

parth/sample-unmarshal-json-for-params

brucemacd/jomorganca/mistral

pdevine/bfloat16

jmorganca/mistral

brucemacd/mistral

pdevine/logging

parth/sample-correctness-fix

parth/sample-fix-sorting

jmorgan/sample-fix-sorting-extras

jmorganca/temp-0-images

brucemacd/parallel-embed-models

brucemacd/shim-grammar

jmorganca/fix-gguf-error

bmizerany/nameswork

jmorganca/faster-releases

bmizerany/validatenames

brucemacd/err-no-vocab

brucemacd/rope-config

brucemacd/err-hint

brucemacd/qwen2_5

brucemacd/logprobs

brucemacd/new_runner_graph_bench

progress-flicker

brucemacd/forward-test

brucemacd/go_qwen2

pdevine/gemma2

jmorganca/add-missing-symlink-eval

mxyng/next-debug

parth/set-context-size-openai

brucemacd/next-bpe-bench

brucemacd/next-bpe-test

brucemacd/new_runner_e2e

brucemacd/new_runner_qwen2

pdevine/convert-cohere2

brucemacd/convert-cli

parth/log-probs

mxyng/next-mlx

mxyng/cmd-history

parth/templating

parth/tokenize-detokenize

brucemacd/check-key-register

bmizerany/grammar

jmorganca/vendor-081b29bd

mxyng/func-checks

jmorganca/fix-null-format

parth/fix-default-to-warn-json

jmorganca/qwen2vl

jmorganca/no-concat

parth/cmd-cleanup-SO

brucemacd/check-key-register-structured-err

parth/openai-stream-usage

parth/fix-referencing-so

stream-tools-stop

jmorganca/degin-1

brucemacd/install-path-clean

brucemacd/push-name-validation

brucemacd/browser-key-register

jmorganca/openai-fix-first-message

jmorganca/fix-proxy

jessegross/sample

parth/disallow-streaming-tools

dhiltgen/remove_submodule

jmorganca/ga

jmorganca/mllama

pdevine/newlines

pdevine/geems-2b

jmorganca/llama-bump

mxyng/modelname-7

mxyng/gin-slog

mxyng/modelname-6

jyan/convert-prog

jyan/quant5

paligemma-support

pdevine/import-docs

jmorganca/openai-context

jyan/paligemma

jyan/p2

jyan/palitest

bmizerany/embedspeedup

jmorganca/llama-vit

brucemacd/allow-ollama

royh/ep-methods

royh/whisper

mxyng/api-models

mxyng/fix-memory

jyan/q4_4/8

jyan/ollama-v

royh/stream-tools

roy-embed-parallel

bmizerany/hrm

revert-5963-revert-5924-mxyng/llama3.1-rope

royh/embed-viz

jyan/local2

jyan/auth

jyan/local

jyan/parse-temp

jmorganca/template-mistral

jyan/reord-g

royh-openai-suffixdocs

royh-imgembed

royh-embed-parallel

jyan/quant4

royh-precision

jyan/progress

pdevine/fix-template

jyan/quant3

pdevine/ggla

mxyng/update-registry-domain

jmorganca/ggml-static

mxyng/create-context

jyan/v0.146

mxyng/layers-from-files

build_dist

bmizerany/noseek

royh-ls

royh-name

timeout

mxyng/server-timestamp

bmizerany/nosillyggufslurps

royh-params

jmorganca/llama-cpp-7c26775

royh-openai-delete

royh-show-rigid

jmorganca/enable-fa

jmorganca/no-error-template

jyan/format

royh-testdelete

bmizerany/fastverify

language_support

pdevine/ps-glitches

brucemacd/tokenize

bruce/iq-quants

bmizerany/filepathwithcoloninhost

mxyng/split-bin

bmizerany/client-registry

jmorganca/if-none-match

native

jmorganca/native

jmorganca/batch-embeddings

jmorganca/initcmake

jmorganca/mm

pdevine/showggmlinfo

modenameenforcealphanum

bmizerany/modenameenforcealphanum

jmorganca/done-reason

jmorganca/llama-cpp-8960fe8

ollama.com

bmizerany/filepathnobuild

bmizerany/types/model/defaultfix

rmdisplaylong

nogogen

bmizerany/x

modelfile-readme

bmizerany/replacecolon

jmorganca/limit

jmorganca/execstack

jmorganca/replace-assets

mxyng/tune-concurrency

jmorganca/testing

whitespace-detection

jmorganca/options

upgrade-all

scratch

cuda-search

mattw/airenamer

mattw/allmodelsonhuggingface

mattw/quantcontext

mattw/whatneedstorun

brucemacd/llama-mem-calc

mattw/faq-context

mattw/communitylinks

mattw/noprune

mattw/python-functioncalling

rename

mxyng/install

pulse

remove-first

editor

mattw/selfqueryingretrieval

cgo

mattw/howtoquant

api

matt/streamingapi

format-config

mxyng/extra-args

shell

update-nous-hermes

cp-model

upload-progress

fix-unknown-model

fix-model-names

delete-fix

insecure-registry

ls

deletemodels

progressbar

readme-updates

license-layers

skip-list

list-models

modelpath

matt/examplemodelfiles

distribution

go-opts

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/ollama#30792