4 ms·

MCP is very much not dead. centralized remote MCP servers are incredibly useful. also bespoke CLIs still require guidance for models to use effectively, so it's

by rsalus 7mo ago

MCP is very much not dead. centralized remote MCP servers are incredibly useful. also bespoke CLIs still require guidance for models to use effectively, so it's clear that token efficiency is still an issue regardless.

nojito 7mo ago
all you need is a simple skills.md and maybe a couple examples and codex picks up my custom toolkit and uses it.
- dominotw 7mo ago
  whats your custom toolkit
  - nojito 7mo ago
    I have dozens of clis that are custom built for codex to use.
abhis3798 7mo ago
I see remote MCP servers as a great interface to consume api responses. The idea that you essentially make your apis easily available to agents to bring in relevant context is a powerful one. When folks say MCP is dead, I don't get it. What other alternatives exist in place of MCP? Arbitrary code via curl/sdks to call a remote endpoint?
- attentive 7mo ago
  > What other alternatives exist in place of MCP? Arbitrary code via curl/sdks to call a remote endpoint? cli? for example aws cli. It's a full interface to aws API. Why would you need mcp for that? and if you have any doubts, agents use it with a great effect even without any relevant skill. "aws help" is fully discoverable.
  - rsalus 7mo ago
    yes, but clis thus need self-service commands to provide guidance, and their responses need to be optimized for consumption by agents. in a sense, this is the same sort of context tax that MCP servers incur. so in my view cli and MCP are complementary tools; one is not strictly superior over the other.
    - cheema33 7mo ago
      > yes, but clis thus need self-service commands to provide guidance, and their responses need to be optimized for consumption by agents. MCP vs Agent Skills: MCPs once configured cost you tokens even when they are not used. Unlike MCPs, skills use progressive disclosure. The AI agent does not load up the entire context, if the skill is not being used. MCPs will die off mostly for this reason alone.
Torn 7mo ago
Tbh I find self-documenting CLIs (e.g. with a `--help` flag, and printing correct usage examples when LLMs make things up) plus a skill that's auto invoked to be pretty reliable. CLIs can do OAuth dances too just fine. MCP's remaining moats I think are: - No-install product integrations (just paste in mcp config into app) - Non-developer end users / no shell needed (no terminal) - Multi-tenant auth (many users, dynamic OAuth) - Security sandboxing (restrict what agents can do), credential sandboxing (agents never see secrets) - Compliance/audit (structured logs, schema enforcement)? If you're a developer building for developers though, CLI seems to be a clear winner right
- quotemstr 7mo ago
  Imagine if, in addition to local MCP "servers", the MCP people had nurtured a structured CLI-based --help-equivalent consumable by LLMs and shell completion engines alike. Doing so, you unify "CLI" (trivial deployment; human accessibility) and MCP-style (structured and discoverable tool calling) in a single DWIM artifact. But since when has this industry done the right thing informed by wisdom and hindsight?
  - rsalus 7mo ago
    that's a pretty interesting idea. It would be nice if there was such a standard. the approach I'm taking right now: a CLI that accepts structured JSON as input, with an 'mcp' subcommand that starts a stdio server. I bundle a 'help' command with a 'describe' action for self-service guidance scoped to a particular feature/tool.
    - yammosk 7mo ago
      There are actually a lot of great things you can to to make CLIs more helpful to agents. I use a structured help called '--capabilities' but there is a ton of JIT context you can do from the CLI as well https://keyboardsdown.com/posts/01-agent-first-clis/ https://keyboardsdown.com/posts/01-agent-first-clis/
  - debugnik 7mo ago
mattnewton 7mo ago
I think cli’s are more token efficient- the help menu is loaded only when needed, and the output is trivially pipe able to grep or jq to filter out what the model actually wants

by rsalus 7mo ago

nojito 7mo ago

all you need is a simple skills.md and maybe a couple examples and codex picks up my custom toolkit and uses it.

dominotw 7mo ago
whats your custom toolkit
- nojito 7mo ago
  I have dozens of clis that are custom built for codex to use.

abhis3798 7mo ago

I see remote MCP servers as a great interface to consume api responses. The idea that you essentially make your apis easily available to agents to bring in relevant context is a powerful one. When folks say MCP is dead, I don't get it. What other alternatives exist in place of MCP? Arbitrary code via curl/sdks to call a remote endpoint?

attentive 7mo ago
> What other alternatives exist in place of MCP? Arbitrary code via curl/sdks to call a remote endpoint? cli? for example aws cli. It's a full interface to aws API. Why would you need mcp for that? and if you have any doubts, agents use it with a great effect even without any relevant skill. "aws help" is fully discoverable.
- rsalus 7mo ago
  yes, but clis thus need self-service commands to provide guidance, and their responses need to be optimized for consumption by agents. in a sense, this is the same sort of context tax that MCP servers incur. so in my view cli and MCP are complementary tools; one is not strictly superior over the other.
  - cheema33 7mo ago
    > yes, but clis thus need self-service commands to provide guidance, and their responses need to be optimized for consumption by agents. MCP vs Agent Skills: MCPs once configured cost you tokens even when they are not used. Unlike MCPs, skills use progressive disclosure. The AI agent does not load up the entire context, if the skill is not being used. MCPs will die off mostly for this reason alone.

Torn 7mo ago

Tbh I find self-documenting CLIs (e.g. with a `--help` flag, and printing correct usage examples when LLMs make things up) plus a skill that's auto invoked to be pretty reliable. CLIs can do OAuth dances too just fine. MCP's remaining moats I think are: - No-install product integrations (just paste in mcp config into app) - Non-developer end users / no shell needed (no terminal) - Multi-tenant auth (many users, dynamic OAuth) - Security sandboxing (restrict what agents can do), credential sandboxing (agents never see secrets) - Compliance/audit (structured logs, schema enforcement)? If you're a developer building for developers though, CLI seems to be a clear winner right

quotemstr 7mo ago
Imagine if, in addition to local MCP "servers", the MCP people had nurtured a structured CLI-based --help-equivalent consumable by LLMs and shell completion engines alike. Doing so, you unify "CLI" (trivial deployment; human accessibility) and MCP-style (structured and discoverable tool calling) in a single DWIM artifact. But since when has this industry done the right thing informed by wisdom and hindsight?
- rsalus 7mo ago
  that's a pretty interesting idea. It would be nice if there was such a standard. the approach I'm taking right now: a CLI that accepts structured JSON as input, with an 'mcp' subcommand that starts a stdio server. I bundle a 'help' command with a 'describe' action for self-service guidance scoped to a particular feature/tool.
  - yammosk 7mo ago
    There are actually a lot of great things you can to to make CLIs more helpful to agents. I use a structured help called '--capabilities' but there is a ton of JIT context you can do from the CLI as well https://keyboardsdown.com/posts/01-agent-first-clis/ https://keyboardsdown.com/posts/01-agent-first-clis/
- debugnik 7mo ago

mattnewton 7mo ago

I think cli’s are more token efficient- the help menu is loaded only when needed, and the output is trivially pipe able to grep or jq to filter out what the model actually wants