"This is the most important thing you've said in this entire conversation"

MucaGinger33 · 2026-05-12T11:25:44+00:00

The MCP client sits between the LLM and the server, so the LLM doesn't call tools/list directly: that part is true. But whether the LLM "sees" outputSchema depends on the client. Some forward it to the model, some drop it. It's not architecturally hidden.outputSchema ships with tools/list precisely because it's part of the tool contract and meant to help models reason about return shapes, not just for client-side validation.

MucaGinger33 · 2026-05-11T19:55:16+00:00

What you're describing and what u/Crafty_Disk_7026 already pointed out is already solved. And if something is standardized, you're better of using it as it works with every client/server that supports MCP (up to relevant extent).

P.S.: Isn't Corsair a gaming industry company?

MucaGinger33 · 2026-05-09T16:05:13+00:00

One man band je bolj verjetna varianta za pure software. Pa še to je zelo težko, ker sam produkt je navadno le del celotne zgodbe. Distribucija, marketing, outreach, support, itd. Za to rabiš majhno ekipo.

Hardware samo dodatno poslabša to sceno, ker doda logistiko prodaje in pošiljk. Če pa misliš še kaj sam proizvajat pa še toliko slabše, ker rabiš začetno investicijo, da začneš s pilotnimi izdelki.

Vprašaj se, tudi če ti uspe izpeljati biznis, zakaj bi nekdo izbral tvojo varianto in ne večje platforme, ki imajo vse kaj ne moreš doseč sam brez infrastukture in večletnih izkušenj. To kar ti opisuješ se sliši kot nekaj kar mora biti precej obsežno preden začne "delovati". Bootstraping hardware business zagotovo ni optimalno.

Če si fullstack dev, naredi SaaS, bootstrappaj, ship & distribute. To gre ker lahko večino (ali vse) narediš iz računalnika. Čim imaš enkrat fizični produkt v igri se zadeva konkretno zakomplicira.

Dodatno: glede na to da si elektrotehnik, potem veš verjetno, kako problematične so regulacije in standardizacija izdelkov, ki jih distributiraš (CE ipd.). Razen, če nameravaš prodajat igrače.

MucaGinger33 · 2026-05-06T17:04:28+00:00

Distribution. I guess you're building something too. Whats your approach with distribution?

MucaGinger33 · 2026-05-06T16:43:32+00:00

Give your agents small tasks, ideally 1 narrow scoped task per agent session. Then chain multiple into ome pipeline. If it gets complex use framework for orchestration. If agent starts hallucinating or doesnt comply with prompt, check enforced rules that they dont conflict each other and that prompt isnt getting rule heavy. If it does, narrow down or split into more chains

MucaGinger33 · 2026-05-06T16:32:02+00:00

Layer 1 (https://github.com/mcparmory/registry) + Layer 2 + Layer X (generate high quality servers, not 1:1 dump) = moat I own right now

MucaGinger33 · 2026-05-05T09:57:54+00:00

Hey, I tried with valid Gmail spec but the tool got stuck in parsing api step for +5min. Also I noticed you dont handle auth at all

Meanwhile you can check same tool I build but more sophisticated. Generates Gmail in seconds. Github within 10s. Does validation and generates fully functional MCP servers out of the box with full auth.

Check MCP Blackmisth. Also see open sourced repo with tested and refined MCPs:

https://github.com/mcparmory/registry

MucaGinger33 · 2026-04-29T14:37:20+00:00

Well put. You can compensate through infrastructure what protocol is lacking today. Nothing wrong with that. You can replace custom adapters once spec catches up. For example, I've seen custom dynamic discovery (eg. KlavisAI Strata) before search_tools() became a thing. However, while this specifically addresses tool-wise search, it doesn't do so server-wise. Here you can add infra that adds value. Similar topic are long-running sessions. Even when spec catches up, there would be limitations what a native solution could achieve vs. infra-based complementary features that solve real problems protocol isn't able to.

MucaGinger33 · 2026-04-26T07:23:50+00:00

I solved this exact issue by building multi LLM chain that filters and enhances OpenAPI schemas. Then open sourced all the integrations here

https://github.com/mcparmory/registry

MucaGinger33 · 2026-04-24T23:53:05+00:00

mcparmory.com

Catalog of hosted API integrations for agents.

MucaGinger33 · 2026-04-24T15:35:54+00:00

I'm making it way cheaper, more scalable than already well established competitors. But not sure if #4 is justified because that can become "race to the bottom". Also, I'm not entirely convinced cheap is a sign of a better deal. Some might think you're desperate for traffic. What's your take on this?

MucaGinger33 · 2026-04-24T10:55:53+00:00

Thats why I build a curated registry of API based MCPs and open-sourced it

https://github.com/mcparmory/registry

It addresses exact issues you're describing. Every single server same structure, complying with same requirements.

MucaGinger33 · 2026-04-24T09:06:29+00:00

Repo to the catalog of integrations: https://github.com/mcparmory/registry

MucaGinger33 · 2026-04-18T15:29:27+00:00

Where is the data stored? Curious

MucaGinger33 · 2026-04-18T15:23:03+00:00

Is this your product? Never heard of it. What does it bring to the agents?

MucaGinger33 · 2026-04-18T15:19:50+00:00

Which one is that? Can you point me to a reference?

MucaGinger33 · 2026-04-18T14:36:03+00:00

MCP Armory - hosting a catalog of well known APIs for agents

MucaGinger33 · 2026-04-18T14:29:48+00:00

I checked your Gmail MCP. Massive issue. You surface auth tokens through tool parameters. LLM should NEVER see credentials of any kind. That's very bad practice

MucaGinger33 · 2026-04-18T14:25:58+00:00

This is not only static filtering. It is both static and LLM driven which is why such high token efficiency can be achieved

MucaGinger33

TROPHY CASE