Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
3870 connectés 

  FORUM HardWare.fr
  Programmation

  [blabla@olympe] Le topic du modo, dieu de la fibre et du monde

 
 


Dernière réponse
Sujet : [blabla@olympe] Le topic du modo, dieu de la fibre et du monde
flo850

tryptique a écrit :


Oui, mais pourtant ton api le fait. En mettant toute la responsabilité du contrôle sur l'utilisateur.


hein ?  
 
genre c'est pas a l'utilisateur de définir ce qu'il veut ?


Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse
[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 
Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
flo850

tryptique a écrit :


Oui, mais pourtant ton api le fait. En mettant toute la responsabilité du contrôle sur l'utilisateur.


hein ?  
 
genre c'est pas a l'utilisateur de définir ce qu'il veut ?

gfive

sligor a écrit :


Je crois que tu n’as pas compris le point de l’article.
 
On parle d’une CLI qui proposerait la même API qu’un mcp.
La seule différence c’est que c’est appelé via commande + arguments et de l’autre c’est de l’échange de json sur un stream stdio/stdout. Le LLM ne va pas écrire de code. La difference est relativement fine.


 
ah ok, moon mauvais :o
 
Cela dit entre un échange de json et un échange de texte sur le stdio/stdout pour choper les sorties de la commande, je vois pas vraiment la diff non plus
Sauf que le MCP a été pensé pour ça, sa sortie peut être plus complexe et structurée que celle d'une CLI, surtout si ladite CLI n'a pas été pensée pour ce genre d'échanges dès le départ.
Jubijub

tryptique a écrit :


Les mcp sont un puit à token sans fond. Une ligne de commande (ou une api) serait bien meilleure (déjà parce que ça devient scriptable)


 

sligor a écrit :

https://ejholmes.github.io/2026/02/ [...] e-cli.html
 
Perso je suis d’accord avec pas mal de cet article, je préfère avoir à utiliser une CLI + skill pour claude qu’un MCP quand c’est possible.( l’avantage potentiel du mcp c’est que c’est statefull, ça se met aussi à jour automatiquement plus facilement)
 
En plus une CLI + skill c’est plus facile a debugger et à scripter.
 
Bref il y a des pro et cons


 
je suis pas pro MCP, mais disons qu'entre rien et un MCP, c'est bien pratique d'avoir le MCP. A une epoque tous les scripts kiddies faisaient des MCPs pour tout, pourrissaient leurs contextes, et venaient chialer à longueur de reddits que les modèles avaient des context windows trop petites. Ça a clairement donné mauvaise réputation aux MCP, mais c'est pas un mauvaise techno.
Pour des trucs simple, une CLI est preferable.
 
En l'occurence je m'en suis servi pour la soirée, aucun pb de contexte. En plus en general je lui envoie des screenshots, je suis pas sur que ce soit beaucoup plus leger en terme de contexte :D
sligor Au passage les skills peuvent être livré avec des scripts (que le llm n’aura pas a reecrire à chaque fois).
Je ne dis pas que les MCP sont inutiles. Juste que ce n’est pas la panacée
sligor

gfive a écrit :


 
C'est comme un dev qui redévelopperait une lib from scratch à chaque fois qu'il en a besoin parce qu'il sait ce qu'il veut et qu'il peut le faire (il a le skill).
 
Comme ça il peut facilement la debugguer....
 
 
Sauf que la lib elle est turbo testée depuis des lustres, elle a un comportement connu et documenté (alors que le dev à façon par le barbu local aura toujours sa petite spécificité à la con), etc...
Il y a 0 intérêt à utiliser autre chose qu'un MCP pour un outil fiable et documenté, Et je pense que laisser le LLM écrire un code one shot pour faire la même chose qu'un outil est pas loin d'être la solution qui a le moins d'intérêt :o


Je crois que tu n’as pas compris le point de l’article.
 
On parle d’une CLI qui proposerait la même API qu’un mcp.
La seule différence c’est que c’est appelé via commande + arguments et de l’autre c’est de l’échange de json sur un stream stdio/stdout. Le LLM ne va pas écrire de code. La difference est relativement fine.
tryptique

flo850 a écrit :


non
tu ne mets pas la responsabilité du contrôle dans l'outil qui doit être contrôlé


Oui, mais pourtant ton api le fait. En mettant toute la responsabilité du contrôle sur l'utilisateur.
flo850

tryptique a écrit :


* Skills issue / hook
* Hook


non
tu ne mets pas la responsabilité du contrôle dans l'outil qui doit être contrôlé

Hermes le Messager

sligor a écrit :

https://ejholmes.github.io/2026/02/ [...] e-cli.html
 
Perso je suis d’accord avec pas mal de cet article, je préfère avoir à utiliser une CLI + skill pour claude qu’un MCP quand c’est possible.( l’avantage potentiel du mcp c’est que c’est statefull, ça se met aussi à jour automatiquement plus facilement)
 
En plus une CLI + skill c’est plus facile a debugger et à scripter.
 
Bref il y a des pro et cons


 
this
tryptique

flo850 a écrit :

 

* ça evite a claude de malencontreusement télécharger plusieurs TB de données en explorant l'api
* ca permet à l'utilisateur de controler plus facilement le llm avec des permissions spécifiques (genre certains delete ont beaucoup de conséquences, donc non, pas par claude sans confirmation)


* Skills issue / hook
* Hook
gfive

sligor a écrit :

https://ejholmes.github.io/2026/02/ [...] e-cli.html

 

Perso je suis d’accord avec pas mal de cet article, je préfère avoir à utiliser une CLI + skill pour claude qu’un MCP quand c’est possible.( l’avantage potentiel du mcp c’est que c’est statefull, ça se met aussi à jour automatiquement plus facilement)

 

En plus une CLI + skill c’est plus facile a debugger et à scripter.

 

Bref il y a des pro et cons

 

C'est comme un dev qui redévelopperait une lib from scratch à chaque fois qu'il en a besoin parce qu'il sait ce qu'il veut et qu'il peut le faire (il a le skill).

 

Comme ça il peut facilement la debugguer....

 


Sauf que la lib elle est turbo testée depuis des lustres, elle a un comportement connu et documenté (alors que le dev à façon par le barbu local aura toujours sa petite spécificité à la con), etc...
Il y a 0 intérêt à utiliser autre chose qu'un MCP pour un outil fiable et documenté, Et je pense que laisser le LLM écrire un code one shot pour faire la même chose qu'un outil est pas loin d'être la solution qui a le moins d'intérêt :o

flo850

tryptique a écrit :


Évidemment si ton mcp évite à ton IA de réinventer un wrapper de ton api en python à chaque fois :o


 
* ça evite a claude de malencontreusement télécharger plusieurs TB de données en explorant l'api  
* ca permet à l'utilisateur de controler plus facilement le llm avec des permissions spécifiques (genre certains delete ont beaucoup de conséquences, donc non, pas par claude sans confirmation)
sligor https://ejholmes.github.io/2026/02/ [...] e-cli.html
 
Perso je suis d’accord avec pas mal de cet article, je préfère avoir à utiliser une CLI + skill pour claude qu’un MCP quand c’est possible.( l’avantage potentiel du mcp c’est que c’est statefull, ça se met aussi à jour automatiquement plus facilement)
 
En plus une CLI + skill c’est plus facile a debugger et à scripter.
 
Bref il y a des pro et cons
tryptique

flo850 a écrit :


On fourni un mcp pour xo, et ça économise des token par rapport à la rest api, en plus d'apporter une couche de cadrage supplémentaires


Évidemment si ton mcp évite à ton IA de réinventer un wrapper de ton api en python à chaque fois :o

sligor

Dion a écrit :

https://img3.super-h.fr/images/2026/11/09/image.png


https://img3.super-h.fr/images/2026 [...] 011852.jpg  

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)