I don't agree with either. Skills with an API exposed by the service solves both your problems.
The LLM can look at the OpenAPI spec and construct queries - I often do this pretty easily.
The LLM can look at the OpenAPI spec and construct queries - I often do this pretty easily.
Skills with an API exposed by the service usually means your coding agent can access the credentials for that service. This means that if you are hit by a prompt injection the attacker can steal those credentials.
As the article states, LLMs are fantastic at writing code, and not so good at issuing tool calls.
tbh, that companies tried to make something proprietary of this concept is probably why its adoption has been weak and why we have "MCP vs CLI/Skills/etc" debates in the first place. In contrast, CLI tools only require a general a bash shell (potentially in a sandbox environment), which is very standardised.
Also even with above there is more opportunity for the bot to go off piste and run cat this and awk that. Meanwhile the "operator" i.e. the Grandpa who has an iPhone but never used a computer has no chance of getting the bot back on track as he tries to renew his car insurance.
"Just going to try using sed to get the output of curl https://.."
"I don't understand I just want to know the excess for not at fault incident when the other guy is uninsured".
Everyone has gone claw-brained. But it really is ok to write code and save that code to disk and execute thay code later.
You can use MCP or even just hard coded API call from your back end to the service you wanna use like it's 2022.