Oleg Rakitskiy 🇺🇦

@y_honcharenko Так це ж перше правило спорту: не знаєш шо робити? - тягай залізо :)

@y_honcharenko І десь недавно бачив відос про те, що брити говорять кластерами типу: вочагонаду. Це трохан ускладнює розуміння, якщо хочеш чути кожне слово.

@y_honcharenko Не переживай. Вухо пристосується доволі швидко. Будеш розуміти на ізі.

@gunnarmorling Indeed. Should have used 74 as 0

Can we please stop doing that?

@kashasaltsova @sebastian_brunt Та в apple music будь ласка.

@sebastian_brunt Так

Пані @kashasaltsova, а чи плануєте весь матеріал крихітки додавати під одну сторінку артиста на спотіфай? Бо у вас там Крихітка цахес, Крихітка та Kryhitka і на кожній сторінці різний матеріал. А так хочеться шоб воно було все разом 😭

@y_honcharenko Британських на жаль ні. Але коли я шукав локальні - просто подивився на список найбільш популярних і вибрав те, що «клікнуло»

@y_honcharenko Подкасти. Дуже допомагають.

@y_honcharenko Так

@chaliy @bikatr7 I can understand the need when you want to do stuff that doesn’t have an http endpoint e.g SQL or FS, but still if LLMs are so good - why can’t they talk low level protocols like postgres protocol or rsh for shell operations.

@bikatr7 Everybody confused how MCP got so popular without any advantages over simple HTTP calls 😄

@svpino @chaliy But judging from this github.com/modelcontextpr… for example, it’s just an adapter. Say, sentry rolls out an api that allows to perform an operation that doesn’t exist in the corresponding MCP. Then you need to go and change the MCP.

@raoldev @chaliy Of course it can! The adapter is not just solving that.

The Model Context Protocol (MCP) is not just "another API lookalike." If you think, "Bro, these two ideas are the same," it means you still don't get it. Let's start with a traditional API: An API exposes its functionality using a set of fixed and predefined endpoints. For example, /products, /orders, /invoices. If you want to add new capabilities to an API, you must create a new endpoint or modify an existing one. Any client that requires this new capability will also need modifications to accommodate the changes. That issue alone is a colossal nightmare, but there's more. Let's say you need to change the number of parameters required for one endpoint. You can't make this change without breaking every client that uses your API! This problem brought us "versioning" in APIs, and anyone who's built one knows how painful this is to maintain. Documentation is another issue. If you are building a client to consume an API, you need to find its documentation, which is separate from the API itself (and sometimes nonexistent.) MCP works very differently: First, an MCP server will expose its capabilities as "tools" with semantic descriptions. This is important! Every tool is self-describing and includes information about what the tool does, the meaning of each parameter, expected outputs, and constraints and limitations. You don't need separate documentation because the interface itself is that documentation! One of my favorite parts is when you need to make changes: Let's say you change the number of parameters required by one of the tools in your server. Contrary to the API world, with MCP, you won't break any clients using your server. They will adapt dynamically to the changes! If you add a new tool, you don't need to modify the clients either. They will discover the tool automatically and start using it when appropriate! But this is just the beginning of the fun: You can set your tools so they are available based on context. For example, an MCP server can expose a tool to send messages only to those clients who have logged in first. There's a ton more, but I don't think I need to keep beating this dead horse. AI + MCP > AI + API *micdrop*

@chaliy @svpino I’m a bit confused by the fact, that LLM can’t ”figure out” api operations from a specification on its own, so an adapter is needed.

@svpino Every single aspect you described could be achieved with simple HTTP API /tools and simple OpenAPI spec describing this endpoint. There is no need to design each tool as a separate API.

@y_honcharenko Забий. Якщо їдеш за правилами, і хтось сигналить без причини (без попередження аварійної ситуації) - хай дудить: ти все робиш правильно, і це не твої проблеми.

@skalinets Почати: Читати книжки, блоги, слухати подкасти. Перестати: твітор, ютуб (окрім довгих технічних відео) Не дякуй.

Це кліпове мислення вже заїбало. Я не читаю книжки, блоги, не слухаю подкасти. Лише твітор і ютуб (а поки йде ролик, або їм або скролю твітер, або і те і те). Шо робити?

@Tarik_Shopa @i1337u @skalinets Та я більше якось по фідо. Не в курсі цих новомодних технологій.

@raoldev @i1337u @skalinets Я б вам радив це написати у нас на формі

@i_am_vladyslav @skalinets «Пишете»

@skalinets Бо пишите на python

Напишіть чи я вас бішу, і чому

@hahasver 2-3 сети? Чи 1 сет на 2-3 повтори до відмови?

@y_honcharenko Забий. З часом починаєш цінувати простоту та стислість, замість оцього всього з метафорами та алегоріями.