Here's a concrete example of what composition looks like in practice.
Say your team has an internal `infractl` CLI for managing your deploy infrastructure. No LLM has ever seen it in training data. You add `--mtp-describe` (one function call with any of the SDKs), then open Claude Code and type:
> !mtpcli
> How do I use infractl?
The first line runs `mtpcli`, which prints instructions teaching the LLM the `--mtp-describe` convention: how to discover tools, how schemas map to CLI invocations, how to compose with pipes. The second line causes the LLM to run `infractl --mtp-describe`, get back the full schema, and understand a tool it has never seen in training data. Now you say:
> Write a crontab entry that posts unhealthy pods to the #ops Slack channel every 5 minutes
And it composes your custom CLI with a third-party MCP server it's never touched before:
Your tool, a Slack MCP server, and `jq`, in a pipeline the LLM wrote because it could discover every piece. That script can run in CI, or on a Raspberry Pi. No tokens burned, no inference round-trips. The composition primitives have been here for 50 years. Bash is all you need!
> The ~2,500 MCP servers out there become composable CLI tools you can script and run in CI without an LLM in the loop
That's pretty cool.
The harder part is getting the various coding agents to run !mtpcli by default + getting cli tool maintainers to add --mtp-describe. Creating a standard is hard, I guess.
I ran into this with Claude too. Using the gh CLI worked far better than the GitHub MCP. The model already knows and “understands” CLIs, and this feels like the right abstraction level for making tools discoverable without breaking composability.
Obviously the model has likely been trained on gh CLI already, but that just reinforces the idea that CLIs are a natural interface for models when discovery is handled well.
Here's a concrete example of what composition looks like in practice.
Say your team has an internal `infractl` CLI for managing your deploy infrastructure. No LLM has ever seen it in training data. You add `--mtp-describe` (one function call with any of the SDKs), then open Claude Code and type:
The first line runs `mtpcli`, which prints instructions teaching the LLM the `--mtp-describe` convention: how to discover tools, how schemas map to CLI invocations, how to compose with pipes. The second line causes the LLM to run `infractl --mtp-describe`, get back the full schema, and understand a tool it has never seen in training data. Now you say: And it composes your custom CLI with a third-party MCP server it's never touched before: Your tool, a Slack MCP server, and `jq`, in a pipeline the LLM wrote because it could discover every piece. That script can run in CI, or on a Raspberry Pi. No tokens burned, no inference round-trips. The composition primitives have been here for 50 years. Bash is all you need!> The ~2,500 MCP servers out there become composable CLI tools you can script and run in CI without an LLM in the loop
That's pretty cool.
The harder part is getting the various coding agents to run !mtpcli by default + getting cli tool maintainers to add --mtp-describe. Creating a standard is hard, I guess.
I ran into this with Claude too. Using the gh CLI worked far better than the GitHub MCP. The model already knows and “understands” CLIs, and this feels like the right abstraction level for making tools discoverable without breaking composability.
Obviously the model has likely been trained on gh CLI already, but that just reinforces the idea that CLIs are a natural interface for models when discovery is handled well.