Geoffrey Huntley Sorts Dev Tools into S-Tier and F-Tier: What Decides It Is --help and Model Weights

Geoffrey Huntley suggests looking at the developer-tools market through a simple two-step scale: S-tier and F-tier. The criterion, he says, is not SDK elegance or marketing budget. Model weights decide everything. If an agent already knows a tool from training, it gets by without skills and without MCP. The main example is GitHub: models work with it through the gh CLI and need no additional scaffolding.

The MCP vs. CLI debate

Anthropic introduced MCP, the Model Context Protocol, in late 2024 as a unified way to connect external tools to models. The protocol quickly became a de facto standard for integrations, and a whole ecosystem of servers grew up around it. But the approach has critics. Their argument: developers have long had an interface that both humans and machines can understand. It is the command line.

Huntley sides with the CLI, though he does not reject everything else. His logic is simple. A model that has seen thousands of examples of gh usage in repositories, issues, and guides calls its commands with confidence. It hardly needs the tool described in context. Every extra layer, whether an MCP server or a set of skills, takes up space in the context window and adds points of failure.

Why the camps diverge

The S-tier includes companies whose tools models know as second nature. GitHub is the model case: gh has long lived in open repositories, documentation, and discussions, which is the data models learn from. The F-tier holds those whose products did not make it into training sets. The agent either hallucinates flags or needs detailed instructions in every session.

This shifts competitive advantage to a different level. Before, the winner was whoever had the more convenient interface for humans. Now the winner is whoever's interface already sits in the weights. Catching up to such a leader is hard: training a new model takes months, and influencing it from the outside is almost impossible.

Three tips for those who are late

Huntley does not leave newcomers without a plan. He names three steps:

• make --help easy for an agent to read: clear command descriptions, examples, and a predictable output format;
• optimize documentation for agentic web search, because models increasingly look up reference material themselves instead of relying on memory;
• negotiate with labs to include documentation in training data.

The first two steps are available to any team today and cost little. The third requires negotiation and depends on the labs' willingness, but it is the one that moves a tool from F-tier to S-tier in the next generation of models.

What teams should do right now

Check your own CLI through an agent's eyes. Run a model without hints and ask it to solve a typical task with your tool. If it gets flags wrong or cannot find the right command, the problem is in --help, not in the model. Rewrite the help text until the agent succeeds on the first attempt.

Next, turn to documentation. Short pages with ready-made command examples, clear headings, and no marketing copy are indexed better by agentic search and are easier to pull into context. Publish them where models actually search: on the open web, not behind a login.

Finally, do not rush to write an MCP server just because it is fashionable. First make sure the CLI does not solve the problem. If it does, MCP would be an unnecessary layer. If it does not, you have a concrete argument for the protocol. In this sense Huntley's position is pragmatic: choose the interface the model already understands, and make it as transparent as possible.