Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- ai:mcp:nastroje:mcpc [05.05.2026 09:47] – Nový článek: mcpc – univerzální CLI klient pro MCP Petr Nosek
+++ ai:mcp:nastroje:mcpc [05.05.2026 10:20] (aktuální) – Doplněno: jak mcpc funguje technicky, bridge architektura, co AI vidí v kontextu, sdílení instance a paměť, přihlašovací údaje Petr Nosek
@@ Řádek 12: / Řádek 12: @@
 Projekt byl představen na Vibecoding Talks v dubnu 2026 Janem Curnem z Apify. Apify zároveň deklarovalo záměr darovat mcpc do Agentic AI Foundation (AAIF) jako kandidáta na oficiální MCP CLI klient pro shellové prostředí.
+===== Jak mcpc funguje =====
+mcpc stojí na dvou vrstvách: **bridge** (background proces) a **CLI příkazy** (co volá AI nebo uživatel).
+==== Bridge ====
+Při prvním připojení k serveru mcpc nastartuje background bridge proces:
+<code bash>
+mcpc connect mcp.apify.com @apify
+</code>
+Bridge drží otevřené MCP připojení k serveru. Pro vzdálené HTTP servery se jen připojí přes síť. Pro lokální stdio servery (jako Playwright MCP) sám spustí server jako child proces a drží ho živý.
+Bridge zůstává aktivní až do explicitního zavření:
+<code bash>
+mcpc @apify close
+</code>
+Žádný automatický timeout po nečinnosti v dokumentaci popsán není – persistentnost je záměrná, aby bylo připojení okamžitě dostupné bez reconnect overhead.
+==== Průběh volání ====
+Když AI zavolá mcpc příkaz přes ''Bash()'', komunikace probíhá takto:
+<code>
+AI agent
+  → Bash("mcpc @playwright tools-call screenshot url:='https://example.com'")
+      → mcpc CLI
+          → Unix socket IPC
+              → bridge (background proces)
+                  → MCP protokol
+                      → Playwright MCP server
+                  ← výsledek
+              ← výsledek
+          ← výsledek
+      → stdout (text nebo JSON)
+  ← AI vidí pouze tento výstup
+</code>
+AI v žádném bodě tohoto řetězce nevidí přihlašovací údaje ani definice nástrojů, které si explicitně nevyžádala.
+==== Sdílení instance napříč projekty ====
+Bridge je sdílený – pokud se více AI projektů připojí ke stejné pojmenované session, používají jeden společný bridge a tedy jednu instanci MCP serveru:
+<code>
+Bez mcpc:
+  Projekt A → vlastní Playwright instance (150 MB)
+  Projekt B → vlastní Playwright instance (150 MB)
+  Projekt C → vlastní Playwright instance (150 MB)
+  = 450 MB
+S mcpc:
+  Projekt A ↘
+  Projekt B  → mcpc bridge → jedna Playwright instance (150 MB)
+  Projekt C ↗
+  = 150 MB + overhead mcpc bridge (zanedbatelný)
+</code>
+Úspora spočívá ve sdílení jedné instance, ne v automatickém uvolňování paměti po nečinnosti.
+===== Co AI vidí v kontextu =====
+Tohle je jeden z klíčových rozdílů oproti klasickým MCP klientům. Standardní klienti (Claude Code, OpenCode) načtou při startu **všechny** definice nástrojů ze všech nakonfigurovaných MCP serverů do kontextu – ještě než AI začne pracovat.
+S mcpc se do kontextu dostane jen to, co AI explicitně zavolá:
+^ Co AI zavolá ^ Co se dostane do kontextu ^
+| ''mcpc @server tools-list'' | seznam jmen nástrojů (stručný) |
+| ''mcpc @server tools-show search-actors'' | definice jednoho konkrétního nástroje |
+| ''mcpc grep "search"'' | jen nástroje odpovídající hledání |
+| ''mcpc @server tools-call search-actors ...'' | **výsledek** volání (ne definice nástroje) |
+Tomuto přístupu se říká **progressive tool discovery** – AI si definice nástrojů dohledává postupně podle potřeby, ne najednou na začátku. Výsledkem je méně spotřebovaných tokenů a méně context rot.
+===== Přihlašovací údaje a bezpečnost =====
+Jedna z hlavních výhod mcpc je, že **AI nikde v projektu přihlašovací údaje nevidí a nepotřebuje je znát**.
+Standardně se credentials konfigurují jednou přes mcpc CLI (''mcpc login'') a uloží do OS keychain. Bridge je pak předává MCP serveru přes Unix socket IPC – ne přes proměnné prostředí, ne přes stdout, ne přes konfigurační soubory dostupné AI agentovi.
+Z pohledu AI agenta probíhá volání takto:
+<code bash>
+# AI zavolá – žádné tokeny, žádné API klíče
+mcpc @apify tools-call search-actors keywords:="scraper"
+# AI dostane – jen výsledek
+</code>
+Přihlašovací údaje jsou tak centrálně spravované a izolované. To má praktické dopady:
+  * AI agent nemusí mít přístup k ''.env'' souborům ani konfiguracím
+  * Pokud agent selže nebo je kompromitovaný, credentials nezíská
+  * Přepínání mezi účty nebo prostředími (dev / prod) se řeší na úrovni mcpc session, ne v kódu projektu
+Pro ještě přísnější izolaci (například nedůvěryhodný AI kód v sandboxu) mcpc nabízí proxy režim:
+<code bash>
+mcpc connect --proxy
+</code>
+V proxy režimu mcpc samo funguje jako MCP server. Agent vidí jen rozhraní proxy – ne přímý přístup k reálnému serveru ani jeho credentials.
 ===== Cíle projektu =====
@@ Řádek 76: / Řádek 181: @@
   | jq '.content[0].text | fromjson | .items[0].id'
 </code>
-Tento přístup je klíčový pro efektivní integraci s AI agenty: agent nepotřebuje znát celou definici MCP serveru dopředu, ale může nástroje postupně objevovat přes ''grep'' a volat je jako kód přes ''Bash()''.
 ===== Klíčové funkce =====
@@ Řádek 91: / Řádek 194: @@
   * OAuth 2.1 s plnou registrací klienta
   * x402 platby (viz níže)
-==== Postupné objevování nástrojů ====
-Místo načtení všech nástrojů do kontextu najednou může agent použít ''grep'' k hledání relevantních nástrojů a načítat jejich definice postupně. To výrazně snižuje spotřebu tokenů a omezuje context rot – jeden ze tří přístupů, které autoři prezentují jako řešení problémů současných MCP klientů.
 ==== Asynchronní úlohy ====
 mcpc podporuje MCP async tasks – dlouhotrvající operace, které server spustí na pozadí. Klient může sledovat jejich průběh a výsledky načítat po dokončení.
-==== MCP proxy pro sandboxované agenty ====
-<code bash>
-mcpc connect --proxy
-</code>
-Proxy režim izoluje přihlašovací údaje před AI agentem. Agent komunikuje přes proxy, ale k samotným credentials nemá přístup – důležité pro bezpečné nasazení v sandboxovaných prostředích, kde kód agenta není plně důvěryhodný.
 ==== x402 platby ====
@@ Řádek 121: / Řádek 212: @@
 | Roots / Elicitation / Completion | 🚧 plánováno |
 | Sampling | ❌ neaplikovatelné |
-===== Bezpečnost =====
-  * OAuth tokeny uloženy výhradně v OS keychain, nikdy na disk
-  * Credentials předávány přes Unix socket IPC, ne přes prostředí
-  * HTTPS vynuceno pro vzdálené servery
-  * OAuth callback vázán pouze na localhost
-  * x402 wallet klíče s oprávněním ''0600''
-  * Credentials nejsou logovány ani ve verbose režimu
 ===== Kontext vzniku =====