5 ms·

It really feels to me that MCP is a fad. Tool calling seems like the overwhelming use case, but a dedicated protocol that goes through arbitrary runtimes is mas

by jjfoooo4 10mo ago

It really feels to me that MCP is a fad. Tool calling seems like the overwhelming use case, but a dedicated protocol that goes through arbitrary runtimes is massive overkill

DANmode 10mo ago
What sort of structure would you propose to replace it? What bodies or demographics could be influential enough to carry your proposal to standardization? Not busting your balls - this is what it takes.
- jascha_eng 10mo ago
  Why replace it at all? Just remove it. I use AI every day and don't use MCP. I've built LLM powered tools that are used daily and don't use MCP. What is the point of this thing in the first place? It's just a complex abstraction over a fundamentally trivial concept. The only issue it solves is if you want to bring your own tools to an existing chatbot. But I've not had that problem yet.
  - p_ing 10mo ago
    > What is the point of this thing in the first place? It's easier for end users to wire up than to try to wire up individual APIs.
  - UncleEntity 10mo ago
    Isn't that the way if works, everybody throws their ideas against the wall and sees what sticks? I haven't really seen anyone recommend using xml in a long while... And isn't this a 'remote' tool protocol? I mean, I've been plugging away at a VM with Claude for a bit and as soon as the repl worked it started using that to debug issues instead of "spray and pray debugging" or, my personal favorite, make the failing tests match the buggy code instead of fixing the code and keeping the correct tests.
  - maxwellg 10mo ago
    > The only issue it solves is if you want to bring your own tools to an existing chatbot. That's a phenomenally important problem to solve for Anthropic, OpenAI, Google, and anyone else who wants to build generalized chatbots or assistants for mass consumer adoption. As well as any existing company or brand that owns data assets and wants to participate as an MCP Server. It's a chatbot app store standard. That's a huge market.
  - tunesmith 10mo ago
    So, I've been playing with an mcp server of my own... the api the mcp talks to is something that can create/edit/delete argument structures, like argument graphs - premises, lemmas, and conclusions. The server has a good syntactical understanding of arguments, how to structure syllogisms etc. But it doesn't have a semantic understanding because it's not an llm. So connecting an llm with my api via MCP means that I can do things like "can you semantically analyze the argument?" and "can you create any counterpoints you think make sense?" and "I don't think premise P12 is essential for lemma L23, can you remove it?" And it will, and I can watch it on my frontend to see how the argument evolves. So in that sense - combining semantic understanding with tool use to do something that neither can do alone - I find it very valuable. However, if your point is that something other than MCP can do the same thing, I could probably accept that too (especially if you suggested what that could be :) ). I've considered just having my backend use an api key to call models but it's sort of a different pattern that would require me to write a whole lot more code (and pay more money).
  - anon84873628 10mo ago
    Ah, so the "I haven't needed it so it must be useless" argument. There is huge value in having vendors standardize and simplifying their APIs instead of having agent users fix each one individually.
    - ianbutler 10mo ago
      Possible legit alternative: Have the agents write code to use APIs? Code based tool calling has literally become a first party way to do tool calling. We have a bunch of code accessible endpoints and tools with years of authentication handling etc built in. https://www.anthropic.com/engineering/advanced-tool-use#:~:text=and%20error%2Dprone.-,Our%20solution,are%20all%20explicit%20in%20code%20rather%20than%20implicit%20in%20Claude%27s%20reasoning.,-Example%3A%20Budget%20compliance https://www.anthropic.com/engineering/advanced-tool-use#:~:t... Feels like this obviates the need for MCP if this is becoming common.
      - anon84873628 10mo ago
        That solution will not work as well when the interfaces have not been standardized in a way that makes it so easy to import them into a script as a library. Coding against every subtly different REST API is as annoying with agents as it is for humans. And it is good to force vendors to define which parts of the interface are actually important and clean them up. Or provide higher level tasks. Why would we ask every client to repeat that work? There are also plenty of environments where having agents dynamically write and execute scripts is neither prudent nor efficient. Local MCP servers strike a governance balance in that scenario, and remote ones eliminate the need entirely.
        simianwords 10mo ago
        I don’t agree on the first part. What sort of llm can’t understand a swagger spec? Why do you think it can’t understand this but can understand mcp? On runtime problems yes maybe we need standardisation.
        10mo ago
  - thomasfromcdnjs 10mo ago
    I have Linear(mcp) connected to ChatGPT and my Claude Desktop, and I use it daily from both. For the MCP nay sayers, if I want to connect things like Linear or any service out there to third party agentic platforms (chatgpt, claude desktop), what exactly are you counter proposing? (I also hate MCP but gets a bit tiresome seeing these conversations without anyone addressing the use case above which is 99% of the use case, consumers)
    - theturtletalks 10mo ago
      Easy. Just tell the LLM to use the Linear CLI or hit their API directly. I’m only half-joking. Older models were terrible at doing that reliably, which is exactly why we created MCP. Our SaaS has a built-in AI assistant that only performs actions for the user through our GraphQL API. We wrapped the API in simple MCP tools that give the model clean introspection and let us inject the user’s authenticated session cookie directly. The LLM never deals with login, tokens, or permissions. It can just act with the full rights of the logged-in user. MCP still has value today, especially with models that can easily call tools but can’t stick to prompt. From what I’ve seen in Claude’s roadmap, the future may shift toward loading “skills” that describe exactly how to call a GraphQL API (in my case), then letting the model write the code itself. That sounds good on paper, but an LLM generating and running API code on the fly is less consistent and more error-prone than calling pre-built tools.
      - Yeroc 10mo ago
        Easy if you ignore the security aspects. You want to hand over your tokens to your LLM so it can script up a tool that can access it? The value I see in MCP is that you can give an LLM access to services via socket without giving it access to the tokens/credentials required to access said service. It provides at least one level of security that way.
        DANmode 10mo ago
        The point of the example seemed to be connecting easily to a scoped GraphQL API.
  - tonmoy 10mo ago
    The less context switching LLMs of current day need to do the better they seem to perform. If I’m writing C code using an agent but my spec needs complex SQL to be retried then it’s better to give access to the spec database through MCP to prevent the LLM from going haywire
  - nextaccountic 10mo ago
    How do I integrate tool calling in an IDE (such as Zed) without MCP?
- ekropotin 10mo ago
  Dynamic code generation for calling APIs, not sure what is a fancy term for this approach.
  - willahmad 10mo ago
    this assumes generated code is always correct and does exactly what's needed.
    - ekropotin 10mo ago
      Same for MCP - there is always a chance an agent will mess up the tool use. This kind of LLM’s non-determinism is something you have to live with. And it’s the reason why I personally think the whole agents thing is way over-hyped - who need systems that only work 2 times out of 3, lol.
      - anon84873628 10mo ago
        The fraction is a lot higher than 2/3 and tool calls are how you give it useful determinism.
        ekropotin 10mo ago
        Even if each agent has 95% reliability, with just 5 agents in the loop the whole thing is just 77% reliable.
        anon84873628 10mo ago
        Well fortunately that's not what actually happens in practice.
  - gzalo 10mo ago
    Something like https://github.com/huggingface/smolagents https://github.com/huggingface/smolagents Needs a sandbox, otherwise blindly executing generated code is not acceptable
- jjfoooo4 10mo ago
  There’s nothing special about llm tools. They’re really just script invocations. A command runner like just does everything you need, and makes the tools available to humans. I wrote a bit on the topic here: https://tombedor.dev/make-it-easy-for-humans/ https://tombedor.dev/make-it-easy-for-humans/
- deleted 10mo ago
  [deleted]
- whoknowsidont 10mo ago
  You don't need to replace it. Just please stop using it. If for nothing else than pure human empathy.
bastardoperator 10mo ago
I'm kind of in the same boat, I'm probably missing something big, this seems like a lot of work to serve a json file with a url.
dist-epoch 10mo ago
MCP is a universal API - a lot of web services are implementing it, this is the value it brings. Now there are CLI tools which can invoke MCP endpoints, since agents in general fare better with CLI tools.
- hahn-kev 10mo ago
  But like, it's just openAPI with an endpoint for getting the schema, like how is that more universal than openAPI?
  - hobofan 10mo ago
    Most of the value lies in its differentiation to OpenAPI and the conventions it brings. By providing an MCP endpoint you signify "we made the API self-describing enough to be usable by AI agents". Most existing OpenAPI specs out there don't clear that bar, as endpoint/parameter descriptions are underdocumented and are unusable without supplementary documentation that is external to the OpenAPI spec.
    - yencabulator 10mo ago
      That sounds like one could publish MCPv2 which is simply OpenAPI that sets a single flag to true in the header. MCP is a lot of duplicate engineering effort for seemingly no gain.
      - whattheheckheck 10mo ago
        Okay... you are tasked with integrating every rest api exposed from Amazon into vscode chatbot. It's easy to do with rest api so how long will it take you to configure that?
        yencabulator 10mo ago
        That's again apples to oranges. The AWS API was not made to be LLM-friendly. The apples to apples comparison would be this: A: - Assume that AWS exposes an LLM-oriented OpenAPI spec. - Take a preexisting OpenAPI client with support for reflection. - Write the plumbing to go between agent tool calls and OpenAPI calls. Schema from OpenAPI becomes schema for tool calls. - You use a preexisting OpenAPI client library, AWS can use a preexisting OpenAPI server library. B: - Assume that AWS exposes an MCP server. - Program an MCP client. - Write the plumbing to go between agent tool calls and MCP calls. Schema from MCP becomes schema for tool calls. - You had to program an MCP client, AWS had to program an MCP server. Where as OpenAPI existed before the concept of agent tool calls, MCP did not. That's why I said MCP is a lot of duplicate engineering effort for seemingly no gain. Preexisting API mechanisms can be used to provide LLM-oriented APIs, that's orthogonal to MCP-as-a-protocol. MCP is quite ugly as a protocol, and has very little reason to exist.
giamma 10mo ago
I am more interested in how MCP can change human interaction with software. Practical example: there exists an MCP server for Jira. Connect that MCP server to e.g. Claude and then you can write prompts like this: "Produce a release notes document for project XYZ based on the Epics associated to version 1.2.3" or "Export to CSV all tickets with worklog related to project XYZ and version 1.2.3. Make sure the CSV includes these columns ....." Especially the second example totally removes the need for the CSV export functionality in Jira. Now imagine a scenario in which your favourite AI is connected via MCP to different services. You can mix and match information from all of them. Alibaba for example is making MCP servers for all of its user-facing services (alibaba mail, cloud drive, etc etc) A chat UI powered by the appropriate MCP servers can provide a lot of value to regular end users and make it possible for people to use their own data easily in ways that earlier would require dedicated software solutions (exports, reports). People could use software for use cases that the original authors didn't even imagine.
- yard2010 10mo ago
  I bet it would work the same with REST API and any kind of specs, be it OpenAPI or even text files. From my humble experience.
  - theshrike79 10mo ago
    It would, but the point of MCP is that it's discoverable by an AI. You can just go change it and it'll know how to use it immediately If you go and change the parameters of a REST API, you need to modify every client that connects to it or they'll just plain not work. (Or you'll have a mess of legacy endpoints in your API) Not a fan, I like the "give an LLM a virtual environment and let it code stuff" approach, but MCP is here to stay as far as I can see.
    - BerislavLopac 10mo ago
      > the point of MCP is that it's discoverable by an AI What exactly makes it more discoverable than, say, pointing the AI to an OpenAPI spec?
rtp4me 10mo ago
I have been creating an MCP server over the past week or so. Based on what I have seen first hand, an MCP can give much richer context to the AI engine just by using very verbose descriptions in the functions. When it the AI tool (Claude Desktop, Gemini, etc) connects to the server, it examines the descriptions in each function and gets much better context on how to use the tool. I don't know if an API can do the same. I have been very, very impressed how much Claude can do with a good MCP.
- JambalayaJimbo 10mo ago
  Can you not just use verbose descriptions in your swagger document?
mooreds 10mo ago
I've been involved with a few MCP servers. MCP seems like an API designed specifically for LLMs/AIs to interact with. Agree that tool calling is the primary use case. Because of context window limits, a 1:1 mapping of REST API endpoint to MCP tool endpoint is usually the wrong approach. Even though LLMs/agents are very good at figuring out the right API call to make. So you can build on top of APIs or other business logic to present a higher level workflow. But many of the same concerns apply to MCP servers as they did to REST APIs, which is why we're seeing an explosion of gateways and other management software for MCP servers. I don't think it is a fad, as it is gaining traction and I don't see what replaces it for a very real use case: tool calling by agents/LLMs.
- beepbooptheory 10mo ago
  > MCP seems like an API designed specifically for LLMs/AIs to interact with I guess I'm confused now, I thought that what it explicitly is.

It really feels to me that MCP is a fad. Tool calling seems like the overwhelming use case, but a dedicated protocol that goes through arbitrary runtimes is massive overkill

DANmode 10mo ago

What sort of structure would you propose to replace it? What bodies or demographics could be influential enough to carry your proposal to standardization? Not busting your balls - this is what it takes.

jascha_eng 10mo ago
Why replace it at all? Just remove it. I use AI every day and don't use MCP. I've built LLM powered tools that are used daily and don't use MCP. What is the point of this thing in the first place? It's just a complex abstraction over a fundamentally trivial concept. The only issue it solves is if you want to bring your own tools to an existing chatbot. But I've not had that problem yet.
- p_ing 10mo ago
  > What is the point of this thing in the first place? It's easier for end users to wire up than to try to wire up individual APIs.
- UncleEntity 10mo ago
  Isn't that the way if works, everybody throws their ideas against the wall and sees what sticks? I haven't really seen anyone recommend using xml in a long while... And isn't this a 'remote' tool protocol? I mean, I've been plugging away at a VM with Claude for a bit and as soon as the repl worked it started using that to debug issues instead of "spray and pray debugging" or, my personal favorite, make the failing tests match the buggy code instead of fixing the code and keeping the correct tests.
- maxwellg 10mo ago
  > The only issue it solves is if you want to bring your own tools to an existing chatbot. That's a phenomenally important problem to solve for Anthropic, OpenAI, Google, and anyone else who wants to build generalized chatbots or assistants for mass consumer adoption. As well as any existing company or brand that owns data assets and wants to participate as an MCP Server. It's a chatbot app store standard. That's a huge market.
- tunesmith 10mo ago
  So, I've been playing with an mcp server of my own... the api the mcp talks to is something that can create/edit/delete argument structures, like argument graphs - premises, lemmas, and conclusions. The server has a good syntactical understanding of arguments, how to structure syllogisms etc. But it doesn't have a semantic understanding because it's not an llm. So connecting an llm with my api via MCP means that I can do things like "can you semantically analyze the argument?" and "can you create any counterpoints you think make sense?" and "I don't think premise P12 is essential for lemma L23, can you remove it?" And it will, and I can watch it on my frontend to see how the argument evolves. So in that sense - combining semantic understanding with tool use to do something that neither can do alone - I find it very valuable. However, if your point is that something other than MCP can do the same thing, I could probably accept that too (especially if you suggested what that could be :) ). I've considered just having my backend use an api key to call models but it's sort of a different pattern that would require me to write a whole lot more code (and pay more money).
- anon84873628 10mo ago
  Ah, so the "I haven't needed it so it must be useless" argument. There is huge value in having vendors standardize and simplifying their APIs instead of having agent users fix each one individually.
  - ianbutler 10mo ago
    Possible legit alternative: Have the agents write code to use APIs? Code based tool calling has literally become a first party way to do tool calling. We have a bunch of code accessible endpoints and tools with years of authentication handling etc built in. https://www.anthropic.com/engineering/advanced-tool-use#:~:text=and%20error%2Dprone.-,Our%20solution,are%20all%20explicit%20in%20code%20rather%20than%20implicit%20in%20Claude%27s%20reasoning.,-Example%3A%20Budget%20compliance https://www.anthropic.com/engineering/advanced-tool-use#:~:t... Feels like this obviates the need for MCP if this is becoming common.
    - anon84873628 10mo ago
      That solution will not work as well when the interfaces have not been standardized in a way that makes it so easy to import them into a script as a library. Coding against every subtly different REST API is as annoying with agents as it is for humans. And it is good to force vendors to define which parts of the interface are actually important and clean them up. Or provide higher level tasks. Why would we ask every client to repeat that work? There are also plenty of environments where having agents dynamically write and execute scripts is neither prudent nor efficient. Local MCP servers strike a governance balance in that scenario, and remote ones eliminate the need entirely.
      - simianwords 10mo ago
        I don’t agree on the first part. What sort of llm can’t understand a swagger spec? Why do you think it can’t understand this but can understand mcp? On runtime problems yes maybe we need standardisation.
        10mo ago
- thomasfromcdnjs 10mo ago
  I have Linear(mcp) connected to ChatGPT and my Claude Desktop, and I use it daily from both. For the MCP nay sayers, if I want to connect things like Linear or any service out there to third party agentic platforms (chatgpt, claude desktop), what exactly are you counter proposing? (I also hate MCP but gets a bit tiresome seeing these conversations without anyone addressing the use case above which is 99% of the use case, consumers)
  - theturtletalks 10mo ago
    Easy. Just tell the LLM to use the Linear CLI or hit their API directly. I’m only half-joking. Older models were terrible at doing that reliably, which is exactly why we created MCP. Our SaaS has a built-in AI assistant that only performs actions for the user through our GraphQL API. We wrapped the API in simple MCP tools that give the model clean introspection and let us inject the user’s authenticated session cookie directly. The LLM never deals with login, tokens, or permissions. It can just act with the full rights of the logged-in user. MCP still has value today, especially with models that can easily call tools but can’t stick to prompt. From what I’ve seen in Claude’s roadmap, the future may shift toward loading “skills” that describe exactly how to call a GraphQL API (in my case), then letting the model write the code itself. That sounds good on paper, but an LLM generating and running API code on the fly is less consistent and more error-prone than calling pre-built tools.
    - Yeroc 10mo ago
      Easy if you ignore the security aspects. You want to hand over your tokens to your LLM so it can script up a tool that can access it? The value I see in MCP is that you can give an LLM access to services via socket without giving it access to the tokens/credentials required to access said service. It provides at least one level of security that way.
      - DANmode 10mo ago
        The point of the example seemed to be connecting easily to a scoped GraphQL API.
- tonmoy 10mo ago
  The less context switching LLMs of current day need to do the better they seem to perform. If I’m writing C code using an agent but my spec needs complex SQL to be retried then it’s better to give access to the spec database through MCP to prevent the LLM from going haywire
- nextaccountic 10mo ago
  How do I integrate tool calling in an IDE (such as Zed) without MCP?
ekropotin 10mo ago
Dynamic code generation for calling APIs, not sure what is a fancy term for this approach.
- willahmad 10mo ago
  this assumes generated code is always correct and does exactly what's needed.
  - ekropotin 10mo ago
    Same for MCP - there is always a chance an agent will mess up the tool use. This kind of LLM’s non-determinism is something you have to live with. And it’s the reason why I personally think the whole agents thing is way over-hyped - who need systems that only work 2 times out of 3, lol.
    - anon84873628 10mo ago
      The fraction is a lot higher than 2/3 and tool calls are how you give it useful determinism.
      - ekropotin 10mo ago
        Even if each agent has 95% reliability, with just 5 agents in the loop the whole thing is just 77% reliable.
        anon84873628 10mo ago
        Well fortunately that's not what actually happens in practice.
- gzalo 10mo ago
  Something like https://github.com/huggingface/smolagents https://github.com/huggingface/smolagents Needs a sandbox, otherwise blindly executing generated code is not acceptable
jjfoooo4 10mo ago
There’s nothing special about llm tools. They’re really just script invocations. A command runner like just does everything you need, and makes the tools available to humans. I wrote a bit on the topic here: https://tombedor.dev/make-it-easy-for-humans/ https://tombedor.dev/make-it-easy-for-humans/
deleted 10mo ago
[deleted]
whoknowsidont 10mo ago
You don't need to replace it. Just please stop using it. If for nothing else than pure human empathy.

bastardoperator 10mo ago

I'm kind of in the same boat, I'm probably missing something big, this seems like a lot of work to serve a json file with a url.

dist-epoch 10mo ago

MCP is a universal API - a lot of web services are implementing it, this is the value it brings. Now there are CLI tools which can invoke MCP endpoints, since agents in general fare better with CLI tools.

hahn-kev 10mo ago
But like, it's just openAPI with an endpoint for getting the schema, like how is that more universal than openAPI?
- hobofan 10mo ago
  Most of the value lies in its differentiation to OpenAPI and the conventions it brings. By providing an MCP endpoint you signify "we made the API self-describing enough to be usable by AI agents". Most existing OpenAPI specs out there don't clear that bar, as endpoint/parameter descriptions are underdocumented and are unusable without supplementary documentation that is external to the OpenAPI spec.
  - yencabulator 10mo ago
    That sounds like one could publish MCPv2 which is simply OpenAPI that sets a single flag to true in the header. MCP is a lot of duplicate engineering effort for seemingly no gain.
    - whattheheckheck 10mo ago
      Okay... you are tasked with integrating every rest api exposed from Amazon into vscode chatbot. It's easy to do with rest api so how long will it take you to configure that?
      - yencabulator 10mo ago
        That's again apples to oranges. The AWS API was not made to be LLM-friendly. The apples to apples comparison would be this: A: - Assume that AWS exposes an LLM-oriented OpenAPI spec. - Take a preexisting OpenAPI client with support for reflection. - Write the plumbing to go between agent tool calls and OpenAPI calls. Schema from OpenAPI becomes schema for tool calls. - You use a preexisting OpenAPI client library, AWS can use a preexisting OpenAPI server library. B: - Assume that AWS exposes an MCP server. - Program an MCP client. - Write the plumbing to go between agent tool calls and MCP calls. Schema from MCP becomes schema for tool calls. - You had to program an MCP client, AWS had to program an MCP server. Where as OpenAPI existed before the concept of agent tool calls, MCP did not. That's why I said MCP is a lot of duplicate engineering effort for seemingly no gain. Preexisting API mechanisms can be used to provide LLM-oriented APIs, that's orthogonal to MCP-as-a-protocol. MCP is quite ugly as a protocol, and has very little reason to exist.

giamma 10mo ago

I am more interested in how MCP can change human interaction with software. Practical example: there exists an MCP server for Jira. Connect that MCP server to e.g. Claude and then you can write prompts like this: "Produce a release notes document for project XYZ based on the Epics associated to version 1.2.3" or "Export to CSV all tickets with worklog related to project XYZ and version 1.2.3. Make sure the CSV includes these columns ....." Especially the second example totally removes the need for the CSV export functionality in Jira. Now imagine a scenario in which your favourite AI is connected via MCP to different services. You can mix and match information from all of them. Alibaba for example is making MCP servers for all of its user-facing services (alibaba mail, cloud drive, etc etc) A chat UI powered by the appropriate MCP servers can provide a lot of value to regular end users and make it possible for people to use their own data easily in ways that earlier would require dedicated software solutions (exports, reports). People could use software for use cases that the original authors didn't even imagine.

yard2010 10mo ago
I bet it would work the same with REST API and any kind of specs, be it OpenAPI or even text files. From my humble experience.
- theshrike79 10mo ago
  It would, but the point of MCP is that it's discoverable by an AI. You can just go change it and it'll know how to use it immediately If you go and change the parameters of a REST API, you need to modify every client that connects to it or they'll just plain not work. (Or you'll have a mess of legacy endpoints in your API) Not a fan, I like the "give an LLM a virtual environment and let it code stuff" approach, but MCP is here to stay as far as I can see.
  - BerislavLopac 10mo ago
    > the point of MCP is that it's discoverable by an AI What exactly makes it more discoverable than, say, pointing the AI to an OpenAPI spec?

rtp4me 10mo ago

I have been creating an MCP server over the past week or so. Based on what I have seen first hand, an MCP can give much richer context to the AI engine just by using very verbose descriptions in the functions. When it the AI tool (Claude Desktop, Gemini, etc) connects to the server, it examines the descriptions in each function and gets much better context on how to use the tool. I don't know if an API can do the same. I have been very, very impressed how much Claude can do with a good MCP.

JambalayaJimbo 10mo ago
Can you not just use verbose descriptions in your swagger document?

mooreds 10mo ago

I've been involved with a few MCP servers. MCP seems like an API designed specifically for LLMs/AIs to interact with. Agree that tool calling is the primary use case. Because of context window limits, a 1:1 mapping of REST API endpoint to MCP tool endpoint is usually the wrong approach. Even though LLMs/agents are very good at figuring out the right API call to make. So you can build on top of APIs or other business logic to present a higher level workflow. But many of the same concerns apply to MCP servers as they did to REST APIs, which is why we're seeing an explosion of gateways and other management software for MCP servers. I don't think it is a fad, as it is gaining traction and I don't see what replaces it for a very real use case: tool calling by agents/LLMs.

beepbooptheory 10mo ago
> MCP seems like an API designed specifically for LLMs/AIs to interact with I guess I'm confused now, I thought that what it explicitly is.