ToolCairnTool Graph
ToolCairn organises 30,000+ developer tools and their relationships as a graph rather than a flat list. The graph captures how tools relate to each other — companions, alternatives, dependencies, ecosystems — so a query like "a TypeScript ORM that plays well with Postgres and Vercel" can be answered with structure, not just keyword overlap.
Why a graph?
Developer tools never exist in isolation. A testing framework needs a language runtime, pairs with a build tool, competes with alternatives, and inherits a licence. Trying to express that with a flat database forces you into joins or — worse — keyword similarity. A graph lets us walk the relationships directly: find tools that work well with Prisma and are written in TypeScript is a single hop, not a cascade of lookups.
What we keep about each tool
Four entities make up the catalog. Most queries traverse them all.
🔧 Tool
A library, framework, CLI, or service. The central entity — every other node connects back to one.
Fields: name · short description · primary language · category · health tier · stars
📂 Category
Functional grouping such as ORM, Testing Framework, CSS Framework, or Build Tool.
Fields: name · slug · tool count
💬 Language
Programming language or runtime — TypeScript, Python, Rust, Go, etc.
Fields: name · slug
📜 License
Software licence the tool ships under (MIT, Apache-2.0, GPL-3.0, …).
Fields: name · SPDX identifier
How tools relate
Six kinds of relationships connect the catalog. Each one is rated by strength, freshness, and how recently it was confirmed by real-world outcomes.
| Relationship | Between | What it means |
|---|---|---|
| Companion | Tool ↔ Tool | Tools that are frequently used together with positive outcomes. Drives stack composition. |
| Alternative | Tool ↔ Tool | Substitutes that solve the same problem in different ways — e.g. Express vs. Fastify. |
| Dependency | Tool → Tool | Runtime or build-time dependency. Powers version-aware compatibility checks. |
| Category membership | Tool → Category | The functional bucket the tool belongs to. |
| Written in | Tool → Language | Primary implementation language. |
| Licensed as | Tool → License | The licence the tool is distributed under. |
What it looks like
A simplified neighbourhood around Prisma — same shape, every tool in the catalog has its own.
┌─────────────┐ works-well-with ┌─────────────┐
│ Prisma │──── (strong) ────▶│ Drizzle │
│ ★ 41.2k │ │ ★ 26.8k │
│ active │ │ active │
└──────┬───────┘ └──────┬──────┘
│ │
written-in written-in
│ │
▼ ▼
┌─────────────┐ ┌──────────────┐
│ TypeScript │ │ TypeScript │
└─────────────┘ └──────────────┘
│
belongs-to
│
▼
┌─────────────┐ alternative-to ┌──────────────┐
│ ORM │ │ Knex.js │
└─────────────┘ └──────────────┘Relationship strength
Every relationship carries a strength signal. Strong relationships rank higher in stack-composition and companion-suggestion queries; weak ones become tie-breakers. The inputs that move strength are:
- Real-world co-usage — how often the tools appear together in published manifests and projects.
- Outcome reports — agents calling
report_outcomereinforce or attenuate pairings based on what worked. - Recency — relationships that haven't seen new evidence in a while fade slowly. See Edge Decay for the mechanism.