Finding an existing capability should come before creating another button. A raw list of names, however, mixes changed code, disabled preferences and unresolved runs into apparently equivalent candidates. I examined what the actual catalog includes and excludes, rather than treating discovery as a simple address book.
Do not forward the library list as execution candidates
ProgramLibrary.catalogue loads each item returned by list again. A definition whose actual code cannot pass its consistency check is excluded from automatic discovery. A lingering display name is not evidence that the current definition is readable and reusable. Catching an error to skip a candidate does not repair the underlying program.
An existing test appends a synthetic modification to workflow code and expects the item to disappear from the catalog; another profile must not discover it either. This is narrower than a general argument for reuse. The question is how current the candidate data is and which state it communicates before a caller even considers starting work.
Query scoring orders results; it does not judge suitability
The query becomes lowercase words. The function counts matches in names, historical intent, sites and parameter labels, then sorts by score followed by recent use and returns at most twenty entries. That is the current discovery bound, not a proposed limit on future capabilities or articles.
Crucially, it is not a filter rejecting every zero-score entry. Less relevant candidates may still appear later. A similar title can still describe a procedure that does not belong to the present request. Historical intent is a search hint rather than a new command. Ranking makes inspection easier but must not replace the caller's comparison of actual behavior with what the human currently wants.
Return parameter keys without reviving old values
Catalog parameters are keys and readable labels, not saved titles or bodies presented as today's input. Inspect likewise replaces parameter values with a key array and returns requiresCurrentInputs=True. A caller can learn what shape is needed while preparing current material separately.
The returned recipe still contains steps and destinations, so this is not an unconditional claim that every definition is free of sensitive data. Definitions themselves need proper authoring and review. Actual use still compares current inputs and authorized actions. The boundary prevents convenient discovery from quietly becoming a mechanism for resending an earlier article or business request.
Hiding every review-needed entry would hide recovery too
Ordinary needs_review entries are omitted from automatic discovery. A limited procedure that can reconcile an original article result may remain with requiresReadOnlyReconciliation. It is a way to find a read-only reconciliation path, not a recommendation to start the unresolved action again.
An existing test preserves that particular recovery candidate while excluding it from another profile. The marker does not permit every operation. The actual execution entrance still distinguishes review-needed state and allowed read-only operations. Discoverability and permission to perform a mutation therefore cannot be represented honestly by one undifferentiated available flag.
Current external control checks enabled registration separately
The current MCP management listing returns identity, label, description, usage, enabled and pinned state and input metadata. A program inspect or run request finds the currently registered item and requires enabled state. Knowing a stored program identity alone should not bypass a deliberately disabled capability.
The older workflow broker also tracks inspection within one request. I do not expand that into a claim that the current external program API enforces the identical inspection-history mechanism. The current external path establishes context, registration and enabled checks before connecting to shared pluginRun. Similar vocabulary across entrances does not make their complete contracts identical.
Distinguish absent capability from presently unusable capability
Creating immediately after a failed search can duplicate an existing definition awaiting review or a deliberately disabled feature. Assuming every visible name is usable loses state in the opposite direction. Reading the label, definition, preference and unresolved-run state can lead to different choices: create, restore or reconcile the original result.
This task compared actual source and existing tests without changing the original catalog. The linked module actually tests the narrower rule that automatic registration respects off and removal choices. It does not recreate search ranking or the whole MCP interface. Reading the state of an existing feature deserves a place in the maker story alongside building a new one.