101–110 of 415 posts
Earlier quoted context omitted.
What are the advantages of using an environment that doesn't have access to a CLI, only having to run/maintain your own server, or pay someone else to maintain that server, so AI has access to tools? Can't you just use AI in the said server?
The advantage is that I can have it in my pocket.
I could not agree any less with the author. I don’t want APIs, I want agents to use the same CLI tooling I already use that is locally available. If my agents are using CLI tooling anyways there is no need to add an extra layer via MCP. I don’t want remote MCP calls, I don’t even want remote models but that’s cost prohibitive. If I need to call an API, a skill with existing CLI tooling is more than capable.
What about auth? Authn and authz. Agent should be you always? If not, every API supports keys? If so, no fears about context poisoned agents leaking those keys?
One thing an MCP (server) gives you is a middleware layer to control agent access. Whether you need that is use-case dependent.
Earlier quoted context omitted.
It supports OAuth, IIRC. But I suppose the internal chatbot itself would require auth, and pass that down to the tools it calls.
The chatbot app initiates an OAuth flow, user SSOs, chatbot app receives tokens to its callback URL, then tool calls can access whatever the user can access. If you use the official MCP SDK, it has interfaces you implement for auth, so all you need to do is kick off the OAuth flow with a URL it figures out and hands you, storing the resulting tokens and producing them when requested. It also handles using refresh tok…
I could not agree any less with the author. I don’t want APIs, I want agents to use the same CLI tooling I already use that is locally available. If my agents are using CLI tooling anyways there is no need to add an extra layer via MCP. I don’t want remote MCP calls, I don’t even want remote models but that’s cost prohibitive. If I need to call an API, a skill with existing CLI tooling is more than capable.
Well yes you don’t need those things all the time and who knows if the inventor of mcp had this idea in mind but here we are
I could not agree any less with the author. I don’t want APIs, I want agents to use the same CLI tooling I already use that is locally available. If my agents are using CLI tooling anyways there is no need to add an extra layer via MCP. I don’t want remote MCP calls, I don’t even want remote models but that’s cost prohibitive. If I need to call an API, a skill with existing CLI tooling is more than capable.
Cool cool. Except. What about auth? Authn and authz. Agent should be you always? If not, every API supports keys? If so, no fears about context poisoned agents leaking those keys? One thing an MCP (server) gives you is a middleware layer to control agent access. Whether you need that is use-case dependent.
This is how I am structuring stuff in Claude Code
- Ansible setup github cli, git, atlassian cli, aws-cli, terraform cli tooling
- Claude hooks for checking these cli tools are authenticated and configured
- Claude skills to use the CLI tooling
1. Ask the LLM to build a tool, under your guide and specification, in order do a specific task. For instance, if you are working with embedded systems, build some monitoring interface that allows, with a simple CLI, to do the debugging of the app as it is working, breakpoints, to spawn the emulator, to restart the program from scratch in a second by re-uploading the live image and resetting the microcontroller. This is just an example, I bet you got what I mean.
2. Then write a skill file where the usage of the tool at "1" is explained.
Of course, for simple tasks, you don't need the first step at all. For instance it does not make sense to have an MCP to use git. The agent knows how to use git: git is comfortable for you, to use manually. It is, likewise, good for the LLM. Similarly if you always estimante the price of running something with AWS, instead of an MCP with services discovery and pricing that needs to be queried in JSON (would you ever use something like that?) write a simple .md file (using the LLM itself) with the prices of the things you use most commonly. This is what you would love to have. And, this is what the LLM wants. For complicated problems, instead, build the dream tool you would build for yourself, then document it in a .md file.
Earlier quoted context omitted.
MCP is an API with strictly defined inputs and outputs.
This is obviously not what it is. If I give you APIGW would you be able to implement an MCP server with full functionality without a large amount of middleware?
- "CLIs need to be published, managed, and installed" -- same for MCP servers which you have to define in your config, and they frequently use some kind of "npx mcp-whatever" call.
- "Where do you put the API tokens required to authenticate?" -- where does an MCP server put them? In your home folder? Some .env file? The keychain? Same like CLI tools.
- "Some tools support installing skills via npx skills, but that only works in Codex and Claude Code, not Claude Cowork or standard Claude" -- sure, but you also can't universally define MCP servers for all those tools. You have to go ahead and edit the config anyway.
- "Using a skill often requires loading the entire SKILL.md into the LLM’s context window, rather than just exposing the single tool signature it needs" -- yeah, but it's on-demand rather than exposing ALL MCP servers' tool signatures. Have you ever tried to use playwright MCP?
I just don't buy the "without any setup" argument.