capabilities.search retourne 0 résultat sur toute requête, y compris les tools existants — avec result_confidence "complete"

[spouletmathis]

Symptôme

capabilities.search renvoie systématiquement {"capabilities": [], "total": 0} quelle que
soit la requête, y compris pour des mots-clés qui correspondent à des tools présents dans la
même build. Le résultat est annoncé result_confidence: "complete" — donc un vide affirmé
comme fiable, indiscernable d'un « ce besoin n'est pas couvert ».

Build testée : 5e4eb061d (2026-08-19), 83 commits après v1.25.0, compilée localement.
Appels passés avec --mcp-binary vers la build (vérifié : token.holders répond ici et
retourne Unknown tool sur le Homebrew 1.25.0).

Cas de test

for q in holders token balance lending portfolio; do
  printf "%-12s -> " "$q"
  $BUILD/alter-cli mcp capabilities.search --json "{\"query\":\"$q\"}" \
    --mcp-binary $BUILD/alter-mcp --timeout 90 \
  | python3 -c "import sys,json;d=json.loads(json.loads(sys.stdin.read())['content'][0]['text'])['data'];print('total=',d.get('total'),'ids=',[c.get('id') for c in (d.get('capabilities') or [])])"
done

Observé vs attendu

Observé :
  holders      -> total= 0  ids= []
  token        -> total= 0  ids= []
  balance      -> total= 0  ids= []
  lending      -> total= 0  ids= []
  portfolio    -> total= 0  ids= []
  result_confidence = "complete" à chaque fois

Attendu :
  au moins un résultat pour "holders"   (token.holders existe dans cette build)
  au moins un résultat pour "lending"   (lending.pool_snapshot, lending.spread, lending.events,
                                         lending.positions_batch existent)
  au moins un résultat pour "portfolio" (address.portfolio existe et répond en 1,4 s)

Vérité terrain : ces tools répondent tous normalement quand on les appelle par leur nom
exact dans la même session, sur la même build.

Testé aussi en français (« liste des détenteurs », « total supply ERC-20 », « prix d'un
token RealToken ») : même résultat vide. Ce n'est donc pas un problème de langue de requête.

Effet de bord : capabilities.evaluate devient inutilisable

$BUILD/alter-cli mcp capabilities.evaluate --json '{"network":"gnosis","address":"0x..."}' \
  --mcp-binary $BUILD/alter-mcp
# → Missing required parameter(s): capability_key, contract_address, holder_address, network_id

capabilities.evaluate exige un capability_key. Le seul moyen de découvrir les clés
valides est capabilities.search — qui ne retourne rien. Les deux tools de découverte sont
donc inutilisables ensemble : on ne peut pas évaluer une capacité dont on ne peut pas
apprendre le nom.

À noter que address.inspect expose bien, lui, des capabilityKey exploitables
(transfer_tokens, approve_operator, …) — la donnée existe donc quelque part, elle n'est
simplement pas atteignable par le tool de recherche.

Impact usage

Ce projet applique une règle explicite : avant tout RPC/scraping manuel, vérifier qu'aucun
tool Alter ne couvre déjà le besoin. capabilities.search est l'outil prévu pour cette
vérification. Comme il répond « rien » avec une confiance « complete », il pousse
activement vers le contournement manuel — c'est-à-dire exactement le comportement que la
règle vise à éviter.

Concrètement, sur cette session : la recherche « holders » a renvoyé vide alors que
token.holders existait dans la build testée. Sans lecture des release notes, la
conclusion aurait été « Alter ne sait pas faire, je passe par l'explorer ».

✅ Test d'acceptation

1. capabilities.search {"query":"holders"} retourne au moins une entrée référençant
   token.holders.
2. capabilities.search {"query":"lending"} retourne au moins les tools lending.*
   exposés par la build.
3. Chaque entrée retournée expose un identifiant réutilisable tel quel comme
   capability_key par capabilities.evaluate.
4. Si le registre est réellement vide (cas légitime), la réponse porte
   result_confidence != "complete" et une note actionnable — jamais un vide silencieux
   présenté comme complet.
5. Anti-régression : les tools continuent de répondre quand on les appelle par leur nom
   exact, et address.inspect continue d'exposer ses capabilityKey.

Réserves

Testé sur profil chargé, avec la collection rmm-v3 provisionnée et la chaîne Gnosis
présente, sans clé API explorer. Je n'ai pas vérifié si le registre de capacités dépend
d'un provisionnement particulier — si c'est le cas, l'absence de ce prérequis devrait être
signalée dans la réponse plutôt que rendue par un total de 0.

[spouletmathis]

Retest — build 31076cc86 (v1.25.0 +94 commits) : ✅ corrigé

Build compilée depuis phoenix_0 HEAD 31076cc86, testée via --mcp-binary.
--version affiche 1.25.0 comme la release publique → SHA cité.

Commande rejouée

$BUILD/alter-cli mcp capabilities.search --json '{"query":"lending pool snapshot"}' \
  --mcp-binary $BUILD/alter-mcp --timeout 60

Sortie observée (brute)

{"capabilities":[],"total":0,
 "searched_scope":"generic_business_capabilities",
 "available_capability_keys":["emprunter","deposer","echanger","collateraliser"],
 "hint":"No generic business capability matches \"lending pool snapshot\". This catalog indexes cross-protocol business capabilities (borrow, deposit, swap, collateralize) — not MCP tool names, token symbols or addresses. To discover MCP tools, use tools/list. To inspect what a given contract can actually do, use address.inspect (field capabilityKey) then capabilities.evaluate.",
 "result_confidence":"complete"}

Verdict

Corrigé. Le reproche de l'issue n'était pas le total: 0 en soi, mais le fait
qu'un vide indiscernable d'une panne soit annoncé complete. 71bedccd5 lève
exactement ça : le scope interrogé est nommé, les clés réellement indexées sont
listées, et le hint redirige vers tools/list / address.inspect.

Sur ce cas précis, result_confidence: complete est correct : le catalogue a
bien été interrogé de bout en bout, il ne contient simplement pas de noms de
tools. La confiance porte sur l'exécution de la requête, pas sur l'utilité du
résultat — et c'est maintenant lisible depuis la réponse.

Impact pipeline

RMM n'appelle pas capabilities.search en production. L'apport est pour
l'agent : notre règle projet impose de chercher un tool Alter avant d'écrire du
RPC direct, et un vide muet poussait à conclure à tort qu'aucun tool ne couvrait
le besoin. Le hint corrige ce faux négatif de raisonnement.

Réserves

Testé sur une requête ne matchant rien. Non testé : une requête qui devrait
matcher une des 4 clés (emprunter, deposer, echanger, collateraliser) —
je n'ai pas vérifié que le chemin non-vide fonctionne toujours.

Je ne clos pas l'issue.

[spouletmathis]

Beta-test build locale — ✅ corrigé, et rectification de mon diagnostic initial

Build testée : 31076cc86 (2026-08-20), 94 commits après v1.25.0, dart compile exe,
macOS 26.6.1 arm64. Pas le Homebrew 1.25.0 (vérifié via token.holders).

Correctif identifié : 71bedccd5 — fix(mcp): qualifier le vide de capabilities.search.

🔴 D'abord : le titre de cette issue est faux, et c'est mon erreur

J'ai écrit « retourne 0 résultat sur toute requête, y compris les tools existants ».
La première moitié est fausse. capabilities.search retourne bien des résultats —
je n'avais testé que des requêtes hors de son périmètre :

for q in emprunter borrow deposer collateraliser echanger; do
  $BUILD/alter-cli mcp capabilities.search --json "{\"query\":\"$q\"}" \
    --mcp-binary $BUILD/alter-mcp --timeout 90
done

emprunter       -> total=1 ids=['emprunter']
borrow          -> total=1 ids=['emprunter']       ← matching FR/EN fonctionnel
deposer         -> total=1 ids=['deposer']
collateraliser  -> total=1 ids=['collateraliser']
echanger        -> total=1 ids=['echanger']

Le tool n'a jamais été cassé : il indexe un catalogue de capacités métier
cross-protocoles (4 entrées), pas les noms de tools MCP. Mes requêtes (holders,
token, balance, lending, portfolio) étaient toutes des noms de tools ou des
symboles — hors périmètre par construction. Je laisse le diagnostic erroné visible plutôt
que de réécrire l'issue, pour que le fil reste lisible.

Le vrai défaut était donc le silence sur ce périmètre, pas le moteur de recherche.
Et c'est exactement ce que le correctif traite.

Ce que la build retourne maintenant sur une requête hors périmètre

{
 "capabilities": [],
 "total": 0,
 "searched_scope": "generic_business_capabilities",
 "available_capability_keys": ["emprunter","deposer","echanger","collateraliser"],
 "hint": "No generic business capability matches \"holders\". This catalog indexes
  cross-protocol business capabilities (borrow, deposit, swap, collateralize) — not MCP
  tool names, token symbols or addresses. To discover MCP tools, use tools/list. To
  inspect what a given contract can actually do, use address.inspect (field
  capabilityKey) then capabilities.evaluate.",
 "result_confidence": "complete"
}

Trois champs neufs : searched_scope dit ce qui a été cherché, available_capability_keys
donne l'inventaire complet du catalogue, hint redirige vers tools/list et
address.inspect. Un appelant qui tombe sur ce vide sait maintenant pourquoi il est
vide et où aller.

Effet de bord capabilities.evaluate : levé

Le blocage décrit dans l'issue (impossible d'évaluer une capacité dont on ne peut pas
apprendre le nom) n'existe plus — la clé issue de search est consommable telle quelle :

$BUILD/alter-cli mcp capabilities.evaluate --json '{
  "capability_key":"emprunter","network_id":"gnosis",
  "contract_address":"0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3",
  "holder_address":"0xd39c1B8Ab6Ee36d18Bc6D4bFAF7Bb6D3a45ba75B"}' \
  --mcp-binary $BUILD/alter-mcp

{"capability_key":"emprunter","usage_id":"borrow","state":"preconditionRequired",
 "is_executable":false,"requires_precondition":true,
 "precondition_reason":"L'activation du collatéral (setUserUseReserveAsCollateral) est
  requise sur le pool.",
 "evaluation_basis":"default_assumptions","result_confidence":"partial"}

Réponse utile et actionnable. La chaîne search → evaluate fonctionne de bout en bout.

Test d'acceptation — relecture honnête

Les critères 1 à 3 tels que je les avais écrits (« holders retourne token.holders »)
étaient mal posés : ils demandaient au catalogue de capacités métier d'indexer des noms
de tools, ce qui n'est pas son rôle. Je les considère caducs.

Le critère qui comptait vraiment, le 4, est celui-ci :

4. Si le registre est réellement vide (cas légitime), la réponse porte
   result_confidence != "complete" ET une note actionnable — jamais un vide
   silencieux présenté comme complet.

Partiellement rempli : la note actionnable est là (hint + searched_scope +
available_capability_keys), mais result_confidence vaut toujours complete sur un
total de 0. C'est défendable — la recherche s'est bien exécutée, le vide est un vrai
résultat — et le hint compense largement en pratique. Je ne demande pas de changement,
je le note pour que le choix soit conscient.

Critère 5 (anti-régression) : vert. Les tools répondent par leur nom exact, et
address.inspect continue d'exposer ses capabilityKey.

Verdict : ✅ livré

Mesure : 5/5 requêtes dans le périmètre retournent leur capacité ; les requêtes hors
périmètre retournent un vide qualifié par 3 champs explicatifs au lieu d'un total: 0 nu.

Impact usage

Ce projet applique une règle explicite : avant tout RPC/scraping manuel, vérifier qu'aucun
tool Alter ne couvre déjà le besoin. capabilities.search était l'outil de cette
vérification, et son vide silencieux poussait vers le contournement manuel — le
comportement exact que la règle vise à éviter. Le hint corrige ça en redirigeant vers
tools/list, qui est le bon point d'entrée pour cette question.

Reste un écart de discoverabilité : le nom capabilities.search suggère « chercher ce
qu'Alter sait faire », alors que le tool répond « quelles actions métier ce contrat
expose-t-il ». Le hint le dit maintenant, mais un agent qui cherche un tool tapera
naturellement ici en premier. Rien à corriger dans le code — peut-être dans la description
du tool exposée via tools/list.

Réserves

Profil chargé, Gnosis provisionnée, collection rmm-v3, sans clé API explorer. Catalogue
observé à 4 entrées ; je ne sais pas s'il s'enrichit avec d'autres collections
provisionnées — si oui, available_capability_keys deviendra long et il faudra sans doute
le tronquer.

[spouletmathis]

Beta-test build locale — ✅ inchangé, catalogue métier toujours lisible

Build testée : d5126afb0 (2026-08-21). Pas le Homebrew 1.25.0.

query=portfolio  → total=0, searched_scope=generic_business_capabilities,
                   available_capability_keys=[emprunter, deposer, echanger, collateraliser],
                   hint (redirige vers tools/list + address.inspect), rc=complete
query=emprunter  → total=1, ids=['emprunter']
query=borrow     → total=1, ids=['emprunter']   ← matching FR/EN

capabilities.evaluate sur emprunter + pool RMM v3 : state=preconditionRequired,
is_executable=false, raison setUserUseReserveAsCollateral — réponse actionnable.

Verdict : ✅ livré

Rien à corriger de plus de notre côté. Le vide hors périmètre reste qualifié.

[spouletmathis]

Beta-test build c27f34c38 — ✅ inchangé, catalogue métier toujours lisible

Build testée : phoenix_0 HEAD c27f34c38 (2026-08-21). Pas le Homebrew 1.25.0.

query=portfolio  → total=0, searched_scope=generic_business_capabilities,
                   available_capability_keys=[emprunter, deposer, echanger, collateraliser],
                   hint (redirige vers tools/list + address.inspect), rc=complete
query=emprunter  → total=1, ids=['emprunter']
query=borrow     → total=1, ids=['emprunter']   ← matching FR/EN

capabilities.evaluate sur emprunter + pool RMM v3 (contract_address=0xFb9b4965…, holder_address=0x15ED1e0c…, network_id=gnosis) : state=preconditionRequired, is_executable=false, raison setUserUseReserveAsCollateral — réponse actionnable.

Verdict : ✅ livré

Rien à corriger de plus de notre côté. Le vide hors périmètre reste qualifié.

[spouletmathis]

Beta-test build locale — ✅ pas de régression : vide toujours qualifié

Build testée : c27f34c38 (v1.25.0 +105 commits), dart compile exe, --mcp-binary. Pas le Homebrew 1.25.0.

Correctif d'origine : 71bedccd5. Aucun commit de cette build ne retouche le sujet.

Commande rejouée

$BUILD/alter-cli mcp capabilities.search --json '{"query":"lending pool snapshot"}' \
  --mcp-binary $BUILD/alter-mcp --timeout 40

Et {"query":"token holders"} (besoin réel RMM, découverte emprunteurs).

Observé

capabilities: []
total: 0
searched_scope: generic_business_capabilities
available_capability_keys: [emprunter, deposer, echanger, collateraliser]
hint: …This catalog indexes cross-protocol business capabilities…
      To discover MCP tools, use tools/list…
result_confidence: complete

Le complete reste correct : le catalogue métier a été interrogé, il ne contient pas de noms de tools. token.holders n'y figure pas — c'est tools/list qui l'expose.

Verdict

✅ pas de régression. Le hint actionnable tient.

Impact pipeline

Aucun script RMM n'appelle capabilities.search en prod. Utile au beta-test / découverte. token.holders se trouve via tools/list, pas via ce catalogue.

Réserves

Je ne close pas. Le catalogue ne couvre toujours pas les noms de tools ; c'est le contrat actuel, documenté par searched_scope.