Picking an AI coding tool used to mean opening a list, scanning logos, and hoping the top row was still current. That stopped working the moment the stack split into layers. You now choose a CLI agent, an editor agent, an MCP gateway, a registry, an inference runtime, and a review loop. Those pieces connect. Change one layer and the others move.
That is a graph problem, not a list problem.
I built aicoolies as a Developer Tools Knowledge Graph for that reason. I am Raşit Akyol, a developer in İzmir, and I got tired of directories that treat Claude Code, Docker MCP Gateway, and a vector extension as the same kind of "AI tool." They are not. One writes patches. One isolates MCP servers in containers. One sits inside Postgres. If you flatten them, you pick the wrong default.
What aicoolies is
The public site is a hand-tested catalog of 1280+ AI developer tools, plus written comparisons, reviews, and curated stacks. It is free on the web. It is not a coding agent. It will not edit your repo. It is the map I open before I install something that can.
The homepage is the catalog and the recommended set. The useful work lives one click deeper:
- Tool pages with pricing model, platforms, open-source status, and telemetry notes
- Side-by-side comparisons that end in a verdict, not a feature grid with no conclusion
- Reviews from a local run when I actually installed the thing
- Stacks that show how tools sit together for a job, a role, or a budget
- Public stacks from other developers, so you can see what people actually keep
I do not treat this as another AI-tools dump. A dump answers "what exists." A knowledge graph answers "what sits next to what, and which one should I start with."
Two pages I keep sending people
Grok Build vs Claude Code
Grok Build vs Claude Code exists because both are terminal-friendly coding agents. That pairing is closer than Grok Build versus Cursor. Claude Code is Anthropic's established workflow for reading a codebase, editing files, running commands, and moving across terminal, IDE, and web. Grok Build is newer, xAI-native, and built for TUI and headless use, plan mode, parallel subagents, best-of-N attempts, and controlled command execution.
The page does not call them interchangeable chatbots. Claude Code is the stronger default today: clearer docs, a more mature workflow, and a better fit for careful codebase reasoning. Grok Build earns a seat when you want competing implementations, scriptable headless runs, or an xAI lane next to Anthropic and OpenAI. The trial I recommend is the same bounded bug fix or refactor in both, then compare the diff, the tests, the commands, and the cleanup. Our pick on that page is Claude Code.
Docker MCP Gateway vs Smithery
Docker MCP Gateway vs Smithery is a layer mistake people make constantly. Docker MCP Gateway is an execution control plane. Clients connect once. The gateway starts approved servers as Docker containers, injects credentials, applies restrictions, routes the call, and can log it. Smithery sits higher: discovery, publishing, and managed connections, especially OAuth-heavy SaaS tools.
Smithery wins the managed connect and OAuth carve-out. Docker wins the secure-runtime decision, and that is the harder thing to retrofit. The combined design on the page is explicit. Use Smithery for registry and authorization where that helps. Run approved self-managed servers behind Docker Gateway when isolation matters. Our pick is Docker MCP Gateway because runtime control is the dependency you do not want to add later.
I also ran Docker MCP Gateway locally and wrote the review. On Docker Desktop it started digest-pinned catalog servers, exposed tools through a profile, denied a tool I had removed from the allowlist, and cleaned up ephemeral containers when the client disconnected. It is strong local orchestration for teams already on Docker. It is not a full enterprise authorization layer. Container flags are not RBAC.
A third live page that uses the same method is MCP Registry vs Glama. The official MCP Registry is the vendor-neutral publication layer: canonical names, namespace proof, package metadata, a sync API. Glama consumes that data and adds search, tool schemas, health signals, sandbox analysis, and an operating surface. Publishers should use the official Registry. Buyers who need to find, test, and run servers usually get more from Glama. Complementary, not clones.
How to use it
Name the job, not the category. "I need a terminal agent for a messy repo" is a job. "AI tools" is not.
Open a comparison that already frames the layer. CLI agent versus CLI agent. Gateway versus managed connect. Official registry versus discovery marketplace. Read the verdict and the workflow-fit section before the table. The table is evidence. The verdict is the decision.
If the tool can edit files or run commands, read the review or run the same bounded trial yourself. Only then look at a stack, so you see the surrounding pieces: review, CI, isolation, observability.
What I will not claim
I will not paste traffic charts. I will not score a tool I have not used. I will not pretend aicoolies replaces Futurepedia, There's An AI For That, Toolify, AlternativeTo, StackShare, or G2. Those products are broader directories or review markets. aicoolies is narrower: developer tools, hand-tested, written as a graph of comparisons, reviews, and stacks.
If you want the catalog, start at aicoolies.com. The two comparisons above are live. So is the Docker MCP Gateway review. If a page is wrong, say so in a comment on the page. A correction is more useful than another upvote.
I keep the catalog because I need it for my own stack. If it helps you pick a safer default, that is enough. Short updates go to x.com/aicoolies.
Top comments (0)