Skip to content

refactor: split getAllToolDefinitions into catalog (all registered) vs discovery (health-filtered for tools/list) APIs #377

@coderabbitai

Description

@coderabbitai

Summary

getAllToolDefinitions() and getAvailableToolNames() in src/registry-manager.ts currently serve a dual purpose:

  1. Discovery — returning the health-filtered tool list for tools/list responses (context-only subset in unreachable mode).
  2. Catalog — used by other consumers (e.g., dashboard metrics) that need a stable count of all registered tools regardless of connection state.

This means that during unreachable mode, any consumer calling getAllToolDefinitions() for informational/metrics purposes will see a reduced, context-only count rather than the full registered tool set.

Proposed Change

Split the API into two distinct methods:

  • getAllToolDefinitionsCatalog() (or getToolCatalog()) — always returns the full set from toolLookupCache / registries, ignoring isUnreachableMode(). Intended for stable counts, documentation, metrics, etc.
  • getAllToolDefinitions() — retains current health-filtered behavior (context-only in unreachable mode) for tools/list responses.

Update callers that need stable totals (e.g., dashboard metrics usage of getAllToolDefinitions()) to call the new catalog method instead.

Context

Identified during review of PR #369 (comment).

Splitting discovery/catalog APIs is a larger refactor deferred from PR #369. The current behavior is considered acceptable for the dashboard (informational-only, rebuilds on next health transition), but tracking this here prevents regressions as new consumers of getAllToolDefinitions() are added.

Backlinks

/cc @polaz

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions